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Fundamentals  of  Deductive  Program  Synthesis 

Zohar  Manna  and  Richard  Waldinger 


Abstract — An  informal  tutorial  is  presented  for  program  syn¬ 
thesis,  with  an  emphasis  on  deductive  methods.  According  to  this 
approach,  to  construct  a  program  meeting  a  given  specification, 
we  prove  the  existence  of  an  object  meeting  the  specified  con¬ 
ditions.  The  proof  is  restricted  to  be  sufficiently  constructive, 
in  the  sense  that,  in  establishing  the  existence  of  the  desired 
output,  the  proof  is  forced  to  indicate  a  computational  method 
for  finding  it.  That  method  becomes  the  hasis  for  a  program 
that  can  be  extracted  from  the  proof.  The  exposition  is  based 
on  the  deductive-tnhleau  system,  a  theorem-proving  framework 
particularly  suitable  for  program  synthesis.  The  system  includes  a 
nonclausal  resolution  rule,  facilities  for  reasoning  about  equality, 
and  a  well-founded  induction  rule. 

Index  Terms — Automated  deduction,  deductive  tahleau,  formal 
methods,  program  synthesis,  program  transformation,  specifica¬ 
tions,  theorem  proving. 

I.  INTRODUCTION 

THIS  is  an  introduction  to  program  synthesis,  the  deriva¬ 
tion  of  a  program  to  meet  a  given  specification.  It  focuses 
on  the  deductive  approach,  in  which  the  derivation  task  is 
regarded  as  a  problem  of  proving  a  mathematical  theorem. 

Let  us  outline  this  approach  in  very  general  terms.  We 
here  construct  only  applicative  (functional)  programs.  We  are 
given  a  specification  that  describes  a  relation  between  the 
input  and  output  of  the  desired  program.  The  specification 
does  not  necessarily  suggest  any  method  for  computing  the 
output.  To  construct  a  program  that  meets  the  specification, 
we  prove  the  existence,  for  any  input  object,  of  an  output 
object  that  satisfies  the  specified  conditions.  The  proof  is 
conducted  in  a  background  theory  that  expresses  the  known 
properties  of  the  subject  domain  and  describes  the  primitives 
of  the  programming  language.  The  proof  is  restricted  to  be 
sufficiently  constructive  so  that,  to  establish  the  existence 
of  a  satisfactory  output  object,  it  is  forced  to  indicate  a 
computational  method  for  finding  one.  That  method  becomes 
the  basis  for  a  program  that  can  be  extracted  from  the  proof. 
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In  principle,  many  theorem-proving  methods  can  be  adapted 
for  program  synthesis.  We  have  developed  a  proof  system, 
called  the  deductive  tableau,  that  is  specifically  intended  for 
this  purpose. 

In  this  paper,  we  begin  by  defining  program  synthesis  and 
relating  it  to  other  software  development  technology.  We  then 
introduce  the  deductive-tableau  proof  system  and  show  how 
to  extract  programs  from  tableau  proofs. 

A.  Specifications 

Program  synthesis  begins  with  a  specification;  in  our  case, 
this  is  a  representation  of  the  relationship  between  the  input 
and  output.  A  specification  should  be  a  description  of  the 
purpose  or  expected  behavior  of  the  desired  program;  ideally, 
it  is  close  to  the  intentions  of  the  users  of  the  system.  A 
good  specification  is  clear  and  readable;  we  do  not  care  if  it 
describes  an  efficient  computation,  or  indeed  any  computation 
at  all.  A  program,  on  the  other  hand,  is  primarily  a  description 
of  a  computation,  preferably  an  efficient  one. 

While  many  languages  have  been  proposed  for  specification, 
we  have  settled  on  logic  in  our  own  work,  because  it  is 
quite  general  and  appropriate  for  deductive  methods.  If  other 
languages  are  more  appropriate  for  particular  subject  domains, 
it  is  plausible  that  they  be  translated  into  logic. 

Let  us  give  logical  specifications  for  some  familiar  pro¬ 
grams. 

Example  (Sorting  Specification) 

Suppose  we  would  like  our  programs  to  sort  a  list  of 
numbers.  Then  we  may  be  give  the  specification: 

f  find  z  such  that 

sortW*=\  perm(l,z)  A  ord(z). 

This  specification  is  presented  in  a  background  theory  of  lists 
of  numbers.  For  a  given  input  object,  the  list  l,  the  program 
must  return  an  output  object,  the  list  z,  satisfying  the  condition 
perm(l,  z),  i.e.,  that  z  is  a  permutation  of  l,  and  the  condition 
ord(z),  i.e.,  that  2  is  in  nondecreasing  order.  The  background 
theory  provides  the  meaning  for  the  constructs  perm  and 
ord.  □ 

Note  that  the  specification  provides  a  clear  statement  of  the 
purpose  of  a  sorting  program,  but  does  not  describe  how  we 
want  the  list  to  be  sorted.  A  sorting  program  itself,  such  as 
quicksort  or  mergesort,  does  describe  how  the  computation 
is  to  be  performed,  but  does  not  state  the  purpose  of  the 
program. 

Example  ( Square-Root  Specification) 

Suppose  we  want  a  program  to  find  a  rational  approximation 
to  the  square  root  of  a  nonnegative  rational;  then  we  may  give 
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the  specification 

{find  z  such  that 
if  e  >  0 

then  z2  <  r  A  r  <  (z  +  e)2. 

Here,  we  are  given  the  nonnegative  rational  r  and  positive 
rational  error  tolerance  e  as  inputs.  Our  desired  output  z  is 
less  than  or  equal  to  y/r\  that  is,  z2  <  r,  but  z  +  e  is  strictly 
greater  than  y/f;  that  is,  r  <  (z  +  e)2.  In  other  words,  lies 
in  the  half-open  interval  [z,  z  +  e): 

y/r 


z  z  +  e 

Our  background  theory  is  that  of  the  nonnegative  rationals.  □ 
In  general,  we  shall  be  dealing  with  specifications  of  the 
form 


f(a)  <=  find  z  such  that  Q\a.z\ 
where  Q[a,z]  is  a  sentence  of  the  background  theory. 

B.  Deductive  Software  Technologies 

Program  synthesis  is  one  of  several  methods  to  assist  in  soft¬ 
ware  development  that  is  amenable  to  deductive  techniques. 
Here,  we  mention  some  of  the  other  deductive  software- 
development  methods,  with  representative  references: 

•  Program  Verification.  Proving  that  a  given  program 
meets  a  given  specification  [5],  This  is  the  oldest  of  the 
deductive  methods. 

•  Program  Transformation.  Transforming  a  given  program 
into  a  more  efficient,  perhaps  less  understandable  equiv¬ 
alent  [3]. 

•  Rapid  Prototyping.  Assuring  a  potential  user  that  a  spec¬ 
ification  actually  does  agree  with  his  expectations  [15]. 

•  Logic  Programming.  Executing  a  program  expressed  in 
logic  [20], 

•  Testing.  Exhibiting  inputs  that  cause  a  program  to  fail 
to  meet  its  specification  [42]. 

•  Modification.  Altering  a  given  program  to  reflect 
changes  in  its  specification  or  environment  [9]. 

In  a  somewhat  different  category,  we  may  consider  a  variety 
of  knowledge-based  software  development  methods  (e.g.,  [40]) 
which  rely  on  imitating  the  techniques  of  the  experienced 
programmer.  Automated  deduction  is  exploited  here  in  an 
auxiliary  role;  the  programming  process  is  not  regarded  as 
a  task  of  proving  a  theorem,  but  as  a  task  of  transformation 
with  many  deductive  subtasks. 

Many  researchers  in  formal  methods  for  software  devel¬ 
opment  (e.g.,  [10])  do  regard  programming  as  primarily  a 
deductive  process,  but  are  not  at  all  concerned  with  automating 
the  task;  rather,  they  intend  to  provide  intellectual  tools  for 
the  programmer. 

These  methods  all  rely  on  deductive  techniques,  and  several 
of  them  are  less  ambitious  than  full  program  synthesis.  By 
developing  more  powerful  theorom-proving  techniques  that 
are  specialized  to  software-engineering  application,  we  can 
make  progress  in  several  of  these  areas  at  once. 


C.  Outline  of  Deductive  Program  Synthesis 

In  this  section  we  give  a  more  detailed  outline  of  program 
synthesis  and  its  relation  to  mathematical  proofs. 

In  general,  we  are  given  a  specification 

/(a)  <=  find  z  such  that  Q[n,  zj. 

The  theorem  corresponding  to  this  specification  is 

(Va)(3z)Q[a,  z\. 

In  other  words,  for  every  input  a,  there  exists  an  output  z 
that  satisfies  the  input-output  relation  Q[a.  z].  The  proof  is 
restricted  to  be  sufficiently  constructive  to  indicate  a  method 
for  finding  z  in  terms  of  a.  That  method  is  expressed  by  a 
single  term  t[aj,  which  can  be  extracted  from  the  proof.  The 
term  indicates  which  substitutions  were  made  for  z  to  allow 
the  proof  to  go  through.  The  program  we  produce  is  then 

f(a)  <=  f[a]. 


We  describe  the  method  as  if  there  were  only  one  input  and 
output,  but  in  fact  we  can  have  several  of  each.  If  there  is 
more  than  one  output,  we  define  a  separate  function  for  each. 
In  the  following  example,  there  are  two  outputs. 

Example  (Front/Last  Derivation  Outline) 

In  the  theory  of  finite  strings,  we  would  like  to  construct  a 
program  to  find,  for  a  given  nonempty  string,  s,  two  outputs: 
the  last  character  last(s)  of  s,  and  the  string  front{s)  of  all 
but  the  last  character  of  s.  For  example,  if  s  is  the  string  bada, 
front(s)  is  the  string  bad  and  last.(s)  is  the  character  a. 

The  program  may  be  specified  as 

{ front{s ),  last(s))  <=find  (zi,z2)  such  that 
if  -'(s  =  A) 

then  cfiar(z2)  A  s  =  zj  *  z2 


In  other  words,  s  is  to  be  decomposed  into  the  concatenation 
zj  *z2  of  two  strings,  z\  and  z2,  where  z2  consists  of  a  single 
character.  Here,  A  is  the  empty  string.  Note  that  characters 
are  regarded  as  strings. 

The  theorem  corresponding  to  the  specification  is 


(Vs)(3z1,z2) 


if  — '  (s  =  A) 

then  c/iar(z2)  A  s  =  z\  *  z2 


The  proof  is  restricted  to  be  sufficiently  constructive  to  indicate 
a  method  for  finding  z\  and  z2.  In  this  case,  the  program  we 
shall  extract  from  the  proof  is 


front(s)  <= 


last(s)  <= 


i f  char(s) 
then  A 

else  head(s)  ■  front.  ( t,ail(s )) 

if  char(s) 
then  s 

else  last.  ( tail(s )). 


Here,  head(s)  and  tail{s )  are,  respectively,  the  first  character 
and  the  string  of  all  but  the  first  character  of  the  nonempty 
string  s.  Also,  char(s)  is  true  if  s  consists  of  a  single  character. 
If  c  is  a  character  and  s  is  a  string,  the  prefix  function  c  •  s 
yields  the  result  of  prefixing  c  to  s.  Thus  c  •  s  is  the  same  as 
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c  *  s,  but  c  •  s  is  a  basic  function  defined  only  for  a  character 
and  a  string.  The  concatenation  function  sj  *  S2  is  defined  in 
terms  of  the  prefix  function,  for  any  two  strings  si  and  S2.  □ 

The  structure  of  the  proof  of  the  theorem  determines  the 
structure  of  the  program  we  extract.  In  particular,  a  case 
analysis  in  the  proof  corresponds  to  the  formation  of  a  con¬ 
ditional  or  test  in  the  program.  The  use  of  the  principle 
of  mathematical  induction  in  the  proof  coincides  with  the 
appearance  of  recursion  or  other  repetitive  constructs  in  the 
program.  If  the  proof  requires  some  lemmas,  the  program 
will  invoke  some  auxiliary  subprograms.  Of  course,  different 
proofs  of  the  theorem  may  lead  to  different  programs,  some 
of  which  may  be  preferable  to  others. 

The  phrasing  of  a  specification  as  a  theorem  is  quite 
straightforward.  If  a  proof  is  sufficiently  constructive,  the 
extraction  of  the  program  is  purely  mechanical.  Thus  the 
main  problem  of  deductive  program  synthesis  is  finding  a 
sufficiently  constructive  proof  of  the  theorem.  We  now  turn 
our  attention  to  the  field  of  theorem  proving,  or  automated 
deduction. 

D.  Theorem  Proving 

We  may  distinguish  between  decision  procedures,  which 
guarantee  success  at  proving  theorems  within  a  particular  class, 
and  heuristic  methods,  whose  success  is  not  guaranteed.  We 
may  also  distinguish  between  automatic  systems,  which  act 
without  human  intervention,  and  interactive  systems,  which 
require  it. 

The  theories  of  interest  here,  such  as  those  of  the  nonneg¬ 
ative  integers,  strings,  and  trees,  are  undecidable;  no  decision 
procedures  exist.  We  know  of  no  way  of  restricting  the  spec¬ 
ification  or  programming  language  to  ensure  the  successful 
completion  of  a  proof  without  also  restricting  ourselves  to  a 
trivial  class  of  specifications  and  programs.  We  assume  then 
that  our  theorem  prover  will  employ  heuristic  methods  or  rely 
on  human  guidance — probably  both. 

We  have  distinguished  between  automatic  and  interactive 
systems,  but  this  distinction  is  not  sharp.  Implemented  of 
interactive  systems  introduce  automatic  features  to  reduce 
the  burden  on  the  user.  At  the  same  time,  implemented  of 
automatic  systems  introduce  interactive  controls  so  the  user 
can  assist  the  system  to  discover  proofs  that  are  too  difficult 
to  be  found  automatically. 

Although  interactive  systems  are  amenable  to  gradual  au¬ 
tomation,  most  of  them  are  intended  to  help  the  user  check 
and  flesh  out  a  proof  already  outlined  by  hand,  rather  than  to 
discover  a  new  proof.  The  logical  frameworks  embedded  in 
the  automatic  systems  are  more  conducive  to  proof  discovery. 

The  emphasis  of  this  paper,  however,  is  on  neither  the 
heuristic  aspects  of  theorem  proving  nor  on  the  design  of 
interactive  mechanisms,  but  rather  on  the  development  of 
a  logical  framework  sufficiently  powerful  to  facilitate  the 
discovery  and  succinct  presentation  of  nontrivial  derivation 
proofs. 

Let  us  consider  some  of  the  theorem-proving  systems  that 
have  already  been  developed  to  see  how  appropriate  they 
are  for  our  purpose.  We  discuss  some  automatic  and  some 
interactive  systems. 


We  may  classify  automatic  theorem  provers  according  to 
the  logical  theories  on  which  they  focus: 

•  Predicate  Logic  with  Equality.  Much  work  has  exploited 
the  resolution  [36]  and  paramodulation  [46]  inference 
rules  for  these  theories.  Theorem  provers  based  on  these 
ideas,  such  as  those  developed  at  the  Argonne  National 
Laboratory  [21],  regularly  settle  open  questions  in  math¬ 
ematics  and  logic  [47],  admittedly  in  areas  in  which 
human  intuition  is  weak,  such  as  combinatory  logic  and 
equivalent^]  calculus.  Recent  theorem-proving  systems 
for  predicate  logic  with  equality  have  employed  term- 
rewriting  systems  [19]  and  connection  methods  [1],  [2], 
rather  than  resolution  and  paramodulation,  as  the  primary 
inference  technique. 

*  Theories  with  Induction.  A  separate  body  of  work  fo¬ 
cuses  on  proofs  requiring  the  principle  of  mathematical 
induction.  The  Boyer-Moore  system  [5]  has  been  mo¬ 
tivated  by  and  applied  to  large  problems  in  program 
verification,  but  has  also  been  applied  to  the  interactive 
reconstruction  of  large  proofs  in  mathematics  and  logic, 
such  as  the  Godei  Incompleteness  theorem  [41]. 

All  of  this  work  is  relevant  to  program  synthesis,  yet  it 
is  difficult  to  find  an  existing  system  with  all  the  features 
we  need.  We  require  the  ability  to  prove  theorems  involving 
the  quantifiers  and  connectives  of  first-order  logic  and  the 
mathematical-induction  principle.  The  Argonne  systems,  for 
example,  do  well  with  pure  predicate  logic,  but  have  no 
facilities  for  inductive  proofs.  The  Boyer-Moore  system, 
which  specializes  in  proof  by  induction,  does  not  prove 
theorems  with  existential  quantifiers. 

Many  of  the  interactive  systems  have  grown  out  of  LCF 
[14],  which  was  based  on  Scott’s  “Logic  of  Computable 
Functions.”  Although  these  systems  are  under  user  control, 
they  provide  the  capability  to  encode  commonly  repeated 
patterns  of  inference  as  tactics.  The  system  Isabelle  [34]  arises 
from  LCF,  but  is  generic;  that  is,  it  allows  us  to  describe  a 
new  logic,  then  prove  theorems  in  that  logic  (cf.  [13]). 

Of  particular  relevance  to  program  synthesis  is  the  develop¬ 
ment  of  interactive  systems  to  prove  theorems  in  constructive 
logics.  The  Nuprl  system  [7]  (cf.  [8],  [37],  [17])  is  based 
on  Martin- Lofs  constructive  logic  [30],  [33]  and  has  been 
applied  to  problems  in  program  derivation  as  well  as  mathe¬ 
matics. 

Although  a  derivation  proof  must  be  sufficiently  construc¬ 
tive  to  allow  us  to  extract  a  program,  it  does  not  need  to  be 
carried  out  in  a  constructive  logic.  Typically,  most  of  a  deriva¬ 
tion  proof  has  no  bearing  on  the  program  we  extract;  it  deals 
with  showing  that  a  program  fragment  extracted  from  some 
other  part  of  the  proof  satisfies  some  additional  conditions. 
Since  many  intuitively  natural  steps  are  not  constructive,  it  is 
too  constraining  to  carry  out  the  entire  derivation  proof  in  a 
constructive  logic.  In  our  treatment,  we  adopt  a  classical  logic, 
restricting  it  to  be  constructive  only  when  necessary. 

Most  theorem-proving  systems  can  be  adapted  to  program 
synthesis  and  other  software-engineering  applications.  The 
deductive  framework  we  employ  in  this  paper  is  a  hybrid; 
it  incorporates  ideas  from  resolution  and  inductive  theorem 


MANNA  &  WALDINGER:  FUNDAMENTALS  OF  DEDUCTIVE  PROGRAM  SYNTHESIS 


677 


proving,  and  is  intended  for  both  interactive  and  automatic 
implementation.  An  interactive  synthesis  system,  based  on  the 
theorem  prover  described  in  [6},  has  been  implemented. 

11.  PRELIMINARIES 

In  this  section  we  introduce  some  formal  preliminaries.  We 
are  a  bit  brisk  here;  the  section  may  be  skimmed  by  those 
familiar  with  these  notions.  Those  wishing  a  more  detailed 
explanation  may  refer  to  [25]  and  [29], 

A.  Language 

We  first  define  the  expressions  of  our  language,  which 
consist  of  the  terms  and  the  sentences. 

The  terms  include  the  constants  a,  b,  c, . . .  and  the  variables 
u,v,w . Terms  may  be  constructed  by  the  repeated  ap¬ 
plication  of  function  symbols  to  other  terms.  For 

example,  f(a,g(a,x))  is  a  term.  Also,  if  T  is  a  sentence  and 
s  and  t  are  terms,  the  conditional  (if  T  then  s  else  t)  is  a 
term;  we  call  the  if-then-else  operator  a  term  constructor. 

Atomic  sentences  (or  atoms)  are  constructed  by  apply¬ 
ing  predicate  symbols  p,q,r,...  to  terms.  For  example, 
p(u,  f(a,g(a,  x)))  is  an  atomic  sentence.  We  allow  both  prefix 
and  infix  notations  for  function  and  predicate  symbols.  We 
include  the  equality  symbol  =  as  a  predicate  symbol. 

Sentences  include  the  truth  symbols  true  and  false  and  the 
atomic  sentences;  they  may  be  constructed  by  the  repeated 
application  of  the  connectives  A,  V,  . . .  and  the  quantifiers 
(Vrr)  and  (3x)  to  other  sentences.  We  use  the  notation  if- 
then  for  implication  in  place  of  the  conventional  arrow 
or  horseshoe.  We  include  a  conditional  connective  if-then- 
else ;  in  other  words,  if  IF,  Q,  and  V.  are  sentences  then 
(if  T  then  Q  else  H)  is  also  a  sentence.  We  rely  on  context  to 
distinguish  between  the  conditional  connective  and  conditional 
term  constructor. 

A  closed  expression  contains  no  free  (unquantified)  vari¬ 
ables.  A  ground  expression  contains  no  variables  at  all.  A 
herbrand  expression  is  ground  and  contains  neither  connec¬ 
tives,  term  constructors  nor  equality  symbols;  thus  p(a)  is  a 
herbrand  term,  and  p(a,  f(a,b))  is  a  herbrand  atom. 

B.  Interpretation  and  Truth 

The  truth  of  a  sentence  is  defined  only  with  respect  to  a 
particular  interpretation.  Intuitively  speaking,  we  may  think  of 
an  interpretation  as  a  situation  or  case.  We  adopt  the  Herbrand 
notion  and  define  an  interpretation  as  a  finite  or  infinite  set 
of  herbrand  atoms.  Informally,  we  think  of  the  elements  of 
the  interpretation  as  a  complete  list  of  the  herbrand  atoms  that 
are  true  in  the  corresponding  situation.  The  truth-value  of  any 
closed  sentence  with  respect  to  the  interpretation  is  determined 
by  the  recursive  application  of  the  following  semantic  rules: 

•  A  herbrand  atom  V  is  true  under  an  interpretation  1  if 

Pel. 

•  If  a  sentence  is  not  closed,  we  do  not  define  its  truth- 
value.  Thus  we  do  not  say  whether  p(a:)  is  true  under 
{p(a)}.  Henceforth  in  this  section  we  speak  only  of  closed 
sentences. 


•  A  closed  sentence  (T  A  G)  is  true  under  J  if  T  and  Q  are 
both  true  under  X;  similarly  for  the  other  connectives. 

•  A  closed  sentence  (3i)X‘[a;]  is  true  under  X  if  there  is 
a  herbrand  term  t  such  that  T\t\  is  true  under  X;  here, 
T[t\  is  the  result  of  replacing  all  free  occurrences  of  x  in 
T[x]  with  t.  For  example,  the  sentence  (3:r)p(:r)  is  true 
under  the  interpretation  {p(a)}  because  a  is  a  herbrand 
term  and  p(a )  is  true  under  {p(a}}. 

•  A  closed  sentence  (V2)X[:r]  is  true  under  X  if,  for  every 
herbrand  term  t,  JF[f]  is  true  under  X. 

•  If  (if  V  then  s  else  t )  is  a  closed  term,  a  closed  sentence 
T\if  V  then  s  else  £]  is  true  under  X  if  the  sentence 
(if  V  then  else  F\t\)  is  true  under  X. 

•  For  herbrand  terms  s  and  t,  s  =  t  is  true  under  X  if,  for 
each  herbrand  atom  V(s),  V(s)  €  X  if  and  only  if  V(t)  € 
X.  Here,  V(t)  is  obtained  from  V(s)  by  replacing  exactly 
one  free  occurrence  of  s  with  t.  This  holds  only  when  s 
and  t  are  indistinguishable  under  X.  For  example,  a  —  b 
is  true  under  the  interpretation  { p(a),p(b )},  but  false 
under  the  interpretation  {q(atb),q(a,a)1q(b,b)};  q(a,a) 
belongs  to  the  latter  interpretation,  but  q(b,  a)  does  not. 
In  general,  if  a  closed  sentence  s  =  t  is  true  under  X, 
we  shall  also  say  that  s  =  t  under  X  or  that  s  and  t  are 
equal  under  X. 

Henceforth  we  will  often  say  “sentence”  when  we  mean 
“closed  sentence”. 

C.  Models  and  Theories 

An  interpretation  X  is  a  model  for  a  finite  or  infinite  set 
of  (closed)  sentences  S  if  every  sentence  in  cS  is  true  under 
X.  Thus  the  interpretations  (p(a)}  and  {p(f>)}  are  models 
for  the  set  of  sentences  {(3:c)p(z),  p(a)  Vp(6)},  but  the 
interpretation  (p(6)}  is  not  a  model  for  the  set  of  sentences 
{?(<*)}• 

A  set  of  sentences  S  implies  a  sentence  T  if  T  is  true 
under  every  model  for  S.  For  example,  the  set  {p(a)}  implies 
the  sentence  (3:r)p(2:).  The  theory  TH  defined  by  a  set  of 
sentences  S  is  the  set  of  all  closed  sentences  implied  by  S\ 
this  is  also  called  the  deductive  closure  of  S.  We  say  that  the 
sentences  belonging  to  TH  are  valid  in  the  theory.  We  call  S 
the  set  of  axioms  for  the  theory  TH. 

The  valid  sentences  of  a  theory  are  true  under  every  model 
for  the  theory.  The  contradictory  sentences  of  the  theory  are 
defined  to  be  those  that  are  false  under  every  model  for  the 
theory.  A  sentence  T  is  contradictory  in  the  theory  if  and  only 
if  its  negation  is  valid  in  the  theory. 

The  theory  defined  by  the  empty  set  {  }  of  axioms  is 
predicate  logic,  PL.  For  example,  (3 x)p(x)  V  (Vx)-'p(x)  is 
a  valid  sentence  of  predicate  logic.  Any  interpretation  is  a 
model  for  predicate  logic. 

The  total  reflexive  theory  TR  is  defined  by  the  following 
two  axioms: 

(Vu)  [u  y  u]  (reflexivity) 

(Vu)(Vu)[u  y  v  V  v  y  u]  (totality). 

By  convention,  we  omit  outermost  universal  quantifiers  from 
axioms.  Thus  we  may  write  the  axioms  for  the  total  reflexive 
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theory  TR  as 


7 i  y  u 
u  y  v  V  v  u 


( reflexivity ) 
(totality). 


The  sentence 


(Vx)(Vy)(32)[a  >z  x  A  z  y  y] 


is  valid  in  this  theory.  □ 

When  we  say  that  a  (closed)  sentence  is  valid,  without 
specifying  a  theory,  we  mean  that  it  is  valid  in  predicate  logic. 
If  a  sentence  is  valid  (in  predicate  logic),  it  is  valid  in  any 
theory. 

The  models  for  a  theory  are  the  same  as  the  models  for  its 
axioms.  Intuitively  speaking,  a  model  for  a  theory  corresponds 
to  a  situation  that  could  possibly  happen.  For  example,  an 
interpretation  that  contains  neither  a  y  b  nor  b  y  a  is  not  a 
model  for  the  total  reflexive  theory  TO,  because  it  violates  the 
totality  axiom. 


D.  Substitutions 

A  substitution  is  a  set  {xi  «—  1 1 , . . . ,  xn  «—  t„  }  of  replace¬ 
ment  pairs  x,-  <—  f,-,  where  the  X,-  are  distinct  variables, 
the  t;  are  terms,  and  each  x,-  is  distinct  from  its  corre¬ 
sponding  f,.  Thus  {x  «—  y,  y  «—  g(x)}  is  a  substitution,  but 
{x  «—  a,  x  < —  b)  and  {x  x}  are  not.  The  empty  substitution 
{  }  contains  no  replacement  pairs. 

If  e  is  an  expression  and  0  :  {xi  <—  ti, . . .  ,x„  <—  t„}  is  a 
substitution,  then  eO,  the  result  of  applying  6  to  e,  is  obtained 
by  safely  replacing  each  free  occurrence  of  x,  in  e  with 
the  corresponding  term  t,.  (The  safety  condition  requires  that 
certain  quantified  variables  y  in  e  be  given  a  new  name  y' 
if  some  of  the  terms  t;  also  contain  occurrences  of  y.  For 
details,  see  [25].)  Applying  the  empty  substitution  leaves  an 
expression  unchanged;  that  is,  e{  }  =  e  for  all  expressions  e. 
We  say  that  any  expression  ed  is  an  instance  of  e. 

The  composition  OX  of  two  substitutions  0  and  A  is  a 
substitution  with  the  property  that  e(0A)  =  (e0)A  for  all 
expressions  e.  For  example, 


{x  y}{y  a}  =  {x  *-  a,  y  «-  a} 

=  {y*-z} 

{x  «-  y}{x  +-  a}  =  {x  *-  y}. 


Composition  is  associative  but  not  commutative.  The  empty 
substitution  is  an  identity  under  composition. 

A  substitution  is  a  permutation  if  the  terms  U  are  the  same  as 
the  variables  x,-,  in  some  order.  Thus  {x  ♦—  y,  y  •<—  z,  z  x} 
is  a  permutation;  {x  «—  y}  is  not.  Permutations  are  the  substi¬ 
tutions  with  inverses:  That  is,  7t  is  a  permutation  if  and  only 
if  there  is  some  substitution  7r_J  such  that  7T7r_1  =  {  }. 


A  substitution  9  is  more  general  than  a  substitution  if 
there  exists  a  substitution  A  such  that 


OX  =  4>. 


For  example,  {x  <—  y}  is  more  general  than  {x  a,  y  <—  a}, 
because  {i*-a,  yt-a}  =  {i<-y){y<-  a}.  It  follows  that 
any  substitution  0  is  more  general  than  itself  and  the  empty 
substitution  {  }  is  more  general  than  any  substitution  9. 

A  substitution  0  is  a  unifier  of  two  expressions  d  and  e  if 
dO  and  eO  are  syntactically  identical,  i.e.,  if 


dO  =  eO. 


For  example,  {x  *—  a,  y  *—  6}  is  a  unifier  of  the  two  expres¬ 
sions  p(x,b)  and  p(a,y).  If  two  expressions  have  a  unifier, 
they  are  said  to  be  unifiable. 

A  unifier  of  d  and  e  is  most-general  if  it  is  more  general 
than  any  unifier  of  d  and  e.  For  example,  {x  •<—  y}  and 
{y  *—  x}  are  most-general  unifiers  of  x  and  y.  The  substitution 
0  :  (x  * —  g,  y  * —  n}  is  a  unifier  of  x  and  y,  and  both  {x  •*—  y} 
and  {y  <—  x}  are  more  general  than  0. 

A  unification  algorithm  is  a  procedure  for  testing  whether 
two  expressions  are  unifiable.  If  so,  it  returns  a  most-general 
unifier;  otherwise,  it  returns  a  special  object  nil,  which  is 
distinct  from  any  substitution. 


III.  The  Deductive  Tableau 

Our  proofs  are  represented  by  a  two-dimensional  structure, 
the  deductive  tableau.  Each  row  in  a  tableau  contains  a 
sentence,  either  an  assertion  or  a  goal,  and  an  optional  term, 
the  output  entry.  In  general,  in  a  given  row,  there  may  be  one 
output  entry  for  each  output  of  the  desired  program.  Thus, 
typical  rows  in  a  tableau  have  the  following  form: 


assertions 

goals 

/l(«> 

/n(o) 

A, 

si 

Sti 

Si 

U 

} 


rows 


output  columns 


The  proof  itself  is  represented  by  the  assertions  and  goals  of 
the  tableau;  the  output  entries  serve  for  extracting  a  program 
from  the  proof.  Usually,  we  speak  as  if  our  tableaux  have  only 
a  single  output  column,  but  in  fact  the  results  apply  when  there 
are  several  output  columns  as  well. 

Before  we  describe  the  meaning  of  a  tableau,  let  us  look 
at  an  example. 

Example  (Deductive  Tableau ) 
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assertions 

goals 

■ 

o2) 

z  y  ai  a  c  y  «2 

- 

ti  y  u 

01  02 

A| 

true 

if  a  1  y  02 
then  d] 
else  a 2 

This  tableau  is  part  of  the  derivation  of  a  program  to  find 
an  upper  bound  for  two  objects  a x  and  a 2  in  the  total  reflexive 
theory  TR.  □ 

A.  Suiting  a  Tableau 

We  have  said  that  a  tableau  may  represent  a  proof  and 
a  derivation;  it  may  also  be  regarded  as  a  specification. 
Specifications  describe  sets  of  permissible  output  objects, 
which  are  identified  with  ground  terms.  In  this  section,  we 
gradually  define  what  it  means  for  a  ground  term  to  satisfy 
a  tableau. 

We  first  restrict  our  attention  to  a  particular  interpretation 
and  a  single  row  of  a  tableau. 

Definition  (Suiting  a  Row) 

A  closed  term  t  suits  a  row  |,4|  |H  (or,  respectively,  |  |g|171 ) 
under  an  interpretation  I  if,  for  some  substitution  X,  the 
following  two  conditions  are  satisfied: 

•  Truth  condition.  The  sentence  AX  is  closed  and  false 
under  X  (or,  respectively,  the  sentence  QX  is  closed  and 
true  under  X). 

•  Output  condition.  If  there  is  an  output  entry  s,  the  term 
sX  is  closed  and  sX  equals  t  under  X. 

In  case  the  output  entry  s  is  absent,  the  output  condition  holds 
vacuously.  We  call  X  a  suiting  substitution.  □ 

Example  (Suiting  a  Row) 

If  ai  y  a2  is  true  under  an  interpretation  X,  the  term  ax 
suits  the  row 


:  y  02 


under  X.  To  see  this,  we  take  the  suiting  substitution  X  to  be 
{2  «—  aj}.  The  truth  condition  holds  because  (2  y  a2)A,  that 
is,  ai  >;  a2,  is  closed  and  true  under  X.  The  output  condition 
holds  because  zX,  that  is,  ai,  is  closed  and  equal  to  ai  under  X. 

In  this  example,  the  term  aj  is  actually  identical  to  the 


instance  zX  of  the  output  entry  2.  The  conditional  term 
(i  f  ay  y  a2  then  a 1  else  a 2)  is  also  equal  to  this  instance  of  2 
under  X,  because  aj  y  02  is  true.  Therefore,  even  though  the 
two  terms  are  not  identical,  the  conditional  term  (if  ax  y  a2 
then  ai  else  a2)  also  suits  this  row  under  X.  □ 

If  a  row  has  no  output  entry,  the  output  condition  for  suiting 
a  row  always  holds.  This  means  that,  under  an  interpretation,  if 
some  closed  term  suits  the  row,  then  any  closed  term  suits  the 
row,  since  the  truth  condition  does  not  depend  on  the  term.  In 
a  sense,  a  missing  output  entry  may  be  thought  of  as  a  “don’t 
care”  condition. 

We  have  defined  what  it  means  to  suit  a  single  row;  now 
we  say  what  it  means  to  suit  an  entire  tableau. 

Definition  (Suiting  a  Tableau) 

Under  an  interpretation,  a  closed  term  suits  a  tableau  if  it 
suits  some  row  of  the  tableau.  □ 

If  we  think  of  the  tableau  as  a  specification  and  the  in¬ 
terpretation  as  a  situation  or  case,  the  closed  terms  that  suit 
the  tableau  coincide  with  the  outputs  that  will  meet  the 
specification  in  that  case. 

Example  (Suiting  a  Tableau) 

Let  T  be  the  following  tableau: 


ai  y  02 

0 1 

-.(dl  y  a2) 

a2 

If  ai  >;  a2  is  true  under  X,  then  ai  suits  T  under  X,  with 
the  empty  suiting  substitution  {}.  If,  on  the  other  hand, 
->  (ai  >:  a2)  is  true  under  X,  then  a2  suits  T  under  X.  In 
either  case,  the  conditional  term  (if  a\  y  a2  then  ai  else  a2) 
suits  T  under  X.  □ 


B.  Satisfying  a  Tableau 

The  notion  of  suiting  a  tableau  depends  on  the  interpretation; 
a  term  may  suit  a  tableau  under  one  interpretation  and  not 
under  another.  In  that  sense,  suiting  is  analogous  to  truth 
for  a  sentence.  We  now  introduce  a  notion  of  “satisfying”  a 
tableau,  which  is  independent  of  the  particular  interpretation. 
That  notion  is  analogous  to  validity  for  a  sentence. 

Definition  (Satisfying  a  Tableau) 

In  a  theory  TH,  a  closed  term  t.  satisfies  a  tableau  T  if  t 
suits  T  under  every  model  of  TH.  □ 

If  we  think  of  the  tableau  as  a  specification,  t  corresponds 
to  a  program  that  satisfies  the  specification. 

Example  (Satisfying  a  Tableau) 

Suppose  T  is  the  following  tableau: 


assertions 

goals 

/(«).< 12) 

7  h  a  -2 

7 

a-2  y  ai 

<12 
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Let  our  background  theory  be  the  total  reflexive  theory  TR. 
Then  the  closed  term 

t.  :  if  aj  >  a-2  then  ai  else  02 
satisfies  T  in  TR. 

To  see  this,  consider  an  arbitrary  model  X  for  TR.  We 
distinguish  between  two  cases: 

Case:  dj  >_  a2  is  true  under  X:  In  this  case,  t.  equals  ai 
under  X.  Then  t.  suits  the  first  row 


under  X,  as  we  have  seen.  Therefore  t  suits  T  under  X. 

Case:  a,  >  a?  is  false  under  X:  In  this  case,  t  equals  d2 
under  X.  Also  (by  the  totality  axiom,  since  I  is  a  model  for 
the  total  reflexive  theory  TR),  d2  t.  a  1  is  true  under  X.  Thus 
t  suits  the  second  row 


under  X.  Therefore  t  suits  T  under  X. 

Thus  for  any  model  X  for  the  theory  TR,  t  suits  T  under  X. 
Hence  t  satisfies  the  tableau  in  TR.  □ 

C.  Equivalence  Between  Tableaux 

We  introduce  two  distinct  relations  of  similarity  between 
tableaux.  The  stronger  relation,  equivalence,  requires  that  the 
two  tableaux  always  have  the  same  suiting  terms. 

Definition  (Equivalence  of  Tableaux) 

Two  tableaux  Tj  and  T2  are  equivalent  in  the  theory  TH, 
written  Tj  <->  T2,  if  and  only  if  for  every  closed  term  t  and 
every  model  X  for  TH, 

t  suits  Ti  under  X 
if  and  only  if 

t  suits  T2  under  X.  □ 


That  is,  for  T\  and  T2  to  be  equivalent  in  TH  they  must  have 
the  same  suiting  terms  under  each  model  for  the  theory.  When 
we  say  that  two  tableaux  are  equivalent  without  specifying  a 
theory,  we  mean  that  they  are  equivalent  in  predicate  logic. 
If  two  tableaux  are  equivalent  (in  predicate  logic),  they  are 
equivalent  in  any  theory. 

Eamples  of  equivalent  tableaux  will  be  provided  by  the 
following  basic  properties.  The  proof  of  one  of  these  properties 
is  provided;  the  others  are  similar. 

Property  (Duality) 

For  any  sentences  A  and  Q  and  optional  term  s,  we  have: 


In  other  words,  any  assertion  A  is  equivalent  to  a  goal  (-1.A), 
with  the  same  output  entry  s,  if  any.  Any  goal  Q  is  equivalent 
to  an  assertion  (-'£),  also  with  the  same  output  entry. 

The  equivalence  relation  between  tableaux  has  the  substi- 
tutivity  property  that  if  we  replace  any  subtableau  of  a  given 
tableau  with  an  equivalent  tableau,  we  obtain  an  equivalent 
tableau.  Hence  the  duality  property  allows  us  to  push  any 
assertion  of  a  tableau  into  the  goal  column  by  negating  it, 
obtaining  an  equivalent  tableau. 

It  will  follow  that,  for  any  tableau,  we  can  push  all  the  asser¬ 
tions  into  the  goal  column,  or  all  the  goals  into  the  assertion 
column,  by  negating  them,  thereby  obtaining  an  equivalent 
tableau.  Neverthless,  the  distinction  between  assertions  and 
goals  has  intuitive  appeal  and  possible  strategic  power,  so  we 
retain  it. 

Property  (Renaming) 

For  any  sentences  A  and  Q,  optional  term  s,  and  permutation 
7r,  we  have: 


Applying  a  permutation  to  a  row  has  the  effect  of  system¬ 
atically  renaming  its  free  vairables.  For  example,  by  applying 
the  permutation  it  :  {x  «—  y,  y  *—  z,  z  <—  a:}  to  the  assertion 


we  obtain  the  assertion 


The  property  tells  us  that  these  two  rows  are  equivalent. 

The  renaming  property  states  that  we  can  systematically 
rename  the  free  variables  of  any  row,  obtaining  an  equivalent 
tableau. 

We  prove  the  renaming  property  for  a  goal  row. 

Proof  (Renaming  Property) 

Suppose  the  closed  term  t  suits  the  row 
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under  interpretation  I,  with  suiting  substitution  A.  Then  by 
the  truth  condition, 

(*)  Q\  is  closed  and  true  under  I, 
and  by  the  output  condition, 

(t)  sA  is  closed  and  equal  to  t  under  1. 

We  show  that  then  t  also  suits  the  row 


with  suiting  substitution  7r_1A,  where  7r_1  is  the  inverse  of 
the  permutation  7r. 

To  show  this,  we  show  the  truth  condition, 

(<?7r)  (t^A)  is  closed  and  true  under  J, 
and  the  output  condition, 

(st)  (7r-1A)  is  closed  and  equal  to  t  under  I. 

But  these  follow  from  the  conditions  (*)  and  (t),  because 
by  properties  of  substitutions,  (St)  (t_1A)  =  G(tnt~l)X  = 
G{  }A  =  QX,  and  similarly  for  s. 

In  the  other  direction,  we  assume  that  t  suits  the  row 


with  suiting  substitution  A,  and  can  show  that  t  also  suits  the 
original  row 


with  suiting  substitution  jtA.  □ 

Property  (Instance)  For  any  sentences  A  and  G,  optional 
term  s,  and  substitution  6,  we  have 


the  tableau’s  equivalence.  We  restrict  our  attention  to  a  fixed 
theory  TH. 

Property  (Valid  Assertion  and  Contradictory  Goal) 

Suppose  A  is  a  sentence  whose  every  ground  instance  AS 
is  valid  in  theory  TH;  suppose  G  is  a  sentence  whose  every 
ground  instance  QS  is  contradictory  in  TH.  Then  for  any 
tableau  T  and  term  s, 


in  theory  TH.  In  other  words,  A  may  be  added  as  an  assertion, 
or  Q  as  a  goal,  to  any  tableau,  yielding  an  equivalent  tableau. 

□ 

It  follows  from  the  valid-assertion  property  that  any  row 
\ime\  IH  or  |  LfoMH  can  be  dropped  from  any  tableau.  These 
are  sometimes  called  trivial  rows. 

We  have  defined  validity  in  a  theory  for  closed  sentences 
only.  However,  if  A  is  an  assertion  in  a  tableau  that  is  not 
closed,  we  often  say  that  A  is  a  valid  sentence  when  we 
really  mean  that  every  closed  instance  of  .4  is  valid.  The 
valid-assertion  property  can  then  be  paraphrased  to  say  that 
a  valid  assertion  can  be  added  to  any  tableau,  preserving  its 
equivalence. 

The  following  property  tells  us  more  about  what  it  means 
when  a  row  lacks  an  output  entry. 

Property  (No  output ) 

A  row  (assertion  or  goal)  with  no  output  entry  is  equivalent 
to  one  whose  output  entry  is  a  new  variable;  that  is,  a  variable 
that  does  not  occur  free  in  the  row: 


□ 


The  rationale  here  is  that  if  some  closed  term  suits  either 
of  these  rows,  then  any  closed  term  will.  More  precisely, 
a  closed  term  t  suits  T  with  suiting  substitution  {xj  «— 
«—  if  and  only  if  t  suits  Tu  with  suiting 
substitution  {u  <—  f,  x i  *—  fi,-**,xn  *—  tn). 


It  follows  that  we  may  add  to  a  tableau  any  instance  of  any 
of  its  rows,  obtaining  an  equivalent  tableau.  Note  that,  while 
the  duality  and  renaming  properties  allow  us  to  replace  one 
row  with  another,  the  instance  property  requires  that  we  retain 
the  old  row  while  adding  the  new  one.  If  we  replaced  the  row, 
we  would  not  necessarily  retain  equivalence. 

The  following  property  allows  us  to  add  to  or  remove  from 
a  tableau  any  valid  assertion  or  contrasting  goal,  and  retain 


D.  Primitive  Expressions 

For  some  purposes,  the  notion  of  equivalence  is  too  strong. 
We  may  not  care  if  two  tableaux  are  suited  by  the  same  closed 
terms,  for  each  model  for  the  theory,  so  long  as  they  are 
satisfied  by  the  same  closed  terms.  And  we  may  not  care  if 
they  are  satisfied  by  precisely  the  same  closed  terms,  so  long 
as  they  are  satisfied  by  the  same  closed  terms  that  correspond 
to  computer  programs;  that  is,  those  that  we  know  how  to 
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compute.  This  latter  idea  is  captured  in  the  notion  of  primitive 
terms. 

Definition  (Primitive  Expression) 

Assume  we  are  given  a  finite  set  of  constant,  function,  and 
predicate  symbols,  called  the  primitive  set.  An  expression  is 
said  to  be  primitive  if 

•  It  is  quantifier-free 

•  All  of  its  contant,  function,  and  predicate  symbols  belong 

to  the  primitive  set.  □ 

Note  that  a  primitive  expression  may  contain  variables. 

Intuitively  speaking,  the  primitive  expressions  are  those  we 
know  how  to  compute,  in  terms  of  the  variables  and  the 
elements  of  the  primitive  set.  Typically,  the  primitive  set  will 
include  the  basic  operators  of  the  theory,  plus  those  function 
symbols  for  which  we  have  already  derived  programs.  For 
example,  in  deriving  a  program  to  compute  the  multiplication 
function  in  the  theory  of  the  nonnegative  integers,  we  typically 
include  the  constant  symbol  0,  the  addition  function  symbol 
+,  and  the  equality  predicate  symbol  =  in  the  primitive  set. 

We  can  now  define  a  relation  of  similarity,  weaker  than 
equivalence,  between  tableaux. 

Definition  (Primitively  Similar) 

Two  tableaux  are  primitively  similar  in  theory  TH  if  they 
have  the  same  primitive  satisfying  terms;  that  is,  for  every 
closed  primitive  term  t, 
t.  satisifies  Ti  in  TH 
if  and  only  if 

t  satisfies  T2  in  TH.  □ 

Evidently,  if  two  tableaux  are  equivalent,  they  are  primi¬ 
tively  similar.  Let  us  give  an  example  to  show  that  primitive 
similarity  is  a  strictly  weaker  notion  than  equivalence. 

Example  (Equivalence  Versus  Primitive  Similarity) 

Consider  the  two  tableaux: 


;>(") 

a 

<7(o) 

a 

These  tableau  are  not  equivalent.  If  Jp  is  the  interpretation 
{p(a)},  a  suits  Tp  under  Jp ,  but  a  does  not  suit  Tq  under  Jp. 

On  the  other  hand,  in  the  theory  of  predicate  logic,  no 
closed  term  satisfies  Tp\  in  particular,  no  term  suits  Tp  under 
the  empty  interpretation  {  },  because  p(a)  is  false  under 
{  }.  Similarly,  no  closed  term  satisfies  Tq  in  predicate  logic 
either.  Hence,  the  two  tableaux  are  primitively  similar,  because 
they  are  satisfied  by  precisely  the  same  primitive  satisfying 
terms-namely,  none.  □ 

If  two  tableaux  are  primitively  similar,  they  specify  the  same 
class  of  programs. 


IV.  Properties  of  Deduction  Rules 

Deduction  rules  add  new  rows  to  a  tableau.  They  do  not 
necessarily  preserve  equivalence,  but  they  do  preserve  primi¬ 
tive  similarity;  that  is,  they  maintain  the  set  of  primitive  closed 
terms  that  satisfy  the  tableau.  Thus  the  program  specified  by 
the  tableau  is  unchanged  by  the  application  of  deduction  rules. 


Definition  (Soundness) 

A  rule  for  adding  new  rows  to  a  tableau  is  sound  in  theory 
TH  if  the  same  primitive  closed  terms  satisfy  the  tableau  in 
TH  before  and  after  applying  the  rule.  □ 

We  shall  guarantee  that  each  of  our  deduction  rules  is  sound 
in  the  background  theory. 

Let  us  introduce  some  terminology  for  speaking  about 
deduction  rules.  We  use  the  following  notation  to  describe 
a  rule: 


Here,  the  assertions  Ar  and  the  goals  Qr  are  the  required  rows 
Tr,  which  must  be  present  in  the  tableau  if  the  rule  is  to  be 
applied.  The  assertions  Ag  and  the  goals  Qg  are  the  generated 
rows  Tg,  which  may  be  added  to  the  tableau  by  the  rule. 

The  old  tableau  refers  to  the  tableau  before  the  application 
of  deduction  rules;  if  the  rule  is  applicable,  the  required  rows 
form  a  subtableau  Tr  of  the  old  tableau.  The  new  tableau  refers 
to  the  tableau  after  application  of  the  rule;  it  is  the  union  of 
the  old  tableau  and  the  generated  tableau  Tg. 

Although  we  are  not  yet  ready  to  introduce  the  deduction 
rules  of  our  system,  we  mention  one  of  them  as  an  illustration. 

Example  (If-Split  Rule) 

In  tableau  notation,  the  if-split  rule  is  written 


if  A 
then  Q 

,S 

A 

s 

G 

A 

In  other  words,  if  a  goal  of  the  form  (i  f  A  then  Q)  is  present 
in  the  tableau,  then  we  may  add  the  new  assertion  A  and 
the  new  goal  Q.  The  output  entry  s  for  the  required  goal 
(if  A  then  G),  if  any,  is  inherited  by  the  generated  assertion 
A  and  the  generated  goal  Q.  □ 

A.  Description  of  the  Derivation  Process 

At  this  point  we  describe  the  derivation  process  and  relate 
it  to  the  deductive  tableau  notation. 

We  are  given  a  specification 

/(a)  <=  find  z  such  that  Q[a.  z ] 

in  theory  TH.  We  assume  that  2  is  the  only  free  variable 
in  Q\a,z].  We  are  also  given  a  set  of  primitive  symbols;  to 
allow  the  formation  of  recursive  programs,  we  include  /  in 
the  primitive  set. 

We  form  the  initial  tableau 
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assertions 

goals 

/(«) 

CIM 

A, 

The  input  a  is  taken  to  be  a  constant;  the  output  2  is  a  variable. 
The  assertions  Ai,...,A„  in  the  initial  tableaux  are  known 
to  be  valid  in  TH. 

The  deductive  process  proceeds  by  the  application  of  sound 
deduction  rules  to  the  tableau,  which  add  new  rows  while 
maintaining  primitive  similarity. 

The  process  continues  until  we  obtain  a  final  row,  either 
the  assertion 


false 

t 

or  the  goal 

true 

im 

where  t  is  a  ground  primitive  term.  At  this  point  we  may  stop 
the  derivation  process.  The  program  we  obtain  is 


assertions 

front(s) 

— 

if  -  «  =  A) 

then  char(: 2)  A  s  =  Z)  *  z2 

’1 

-2 

Here,  the  input  s  is  a  constant  and  the  outputs  zj  and  22  are 
variables.  Properties  of  the  theory  of  strings  are  also  included 
in  the  initial  tableau  as  assertions.  For  instance,  the  axioms  for 
the  concatenation  function  are  represented  as  the  assertions 


A  *  y  =  y 

if  char(v) 

then  (v  ■  yi)  *  y2  =  u  •  (yj  *  m) 

By  the  application  of  deduction  rules,  new  rows  are  added 
to  the  tableau,  obtaining  a  primitively  similar  tableau.  The 
process  continues  until  we  ultimately  obtain  the  final  goal 


■ 

if  char(s) 

if  char(s ) 

I 

then  A 

then  s 

true 

1 

else  head(s). 

clsclast(1ail(s)) 

front{tail{s)) 

/(a)  <=  t. 


Example  (Derivation  Process) 

In  the  theory  of  finite  strings,  we  want  to  derive  a  program 
that,  for  a  given  nonempty  string  s,  returns  the  last  character 
of  s  and  the  string  of  all  but  the  last  character  of  s.  Our 
specification  is 


f  find  (21,22)  such  that 


{ front(s ),  last(s))  <=  < 


if  ->  (3  =  A) 
then  char(z2)  A 


s  =  21  *  z2. 


In  other  words,  we  want  to  decompose  s  into  the  concatenation 
21  *  22  of  a  string  21  and  a  character  z2;  then  z2  is  the  last 
character  of  s  and  21  is  the  string  of  all  but  z2.  We  assume 
that  s  is  not  equal  to  the  empty  string  A.  Note  that  for  this 
program  there  are  two  outputs,  z\  and  22-  That  is,  we  need 
to  compute  two  functions,  front  and  last.  The  primitive  set 
includes  all  the  basic  constant,  function,  and  predicate  symbols 
of  the  theory  of  strings,  as  well  as  the  function  symbols  front 
and  last. 

The  corresponding  initial  tableau  then  contains  the  goal 


The  program  we  extract  from  the  proof  is  then 

r  if  char(s) 
front(s)  <=  then  A 

k  else  head(s)  ■  front(tail($)) 
if  char(s) 

last(s)  <£=  ^  then  s 

else  last  (tail(s)). 


□ 

The  correctness  of  the  derivation  process  depends  on  two 
properties  of  tableaux.  We  begin  with  a  definition. 

Definition  (Correctness) 

A  program  /(a)  ■<=  t[a]  is  correct  with  respect  to  the 
specification 

f(a)  <=  find  z  such  that  Q[a,  2] 
if  the  sentence 

(Vi)Q[x,/(i)] 

is  valid  in  the  theory  TH  augmented  with  the  additional  axiom 
(Vx)[/(x)  =  t[x]]. 

□ 

The  additional  axiom  we  add  to  the  theory  is  the  definition 
of  the  new  program  /. 

Property  (Initial  Tableau) 

If  any  closed  term  f[a]  satisfies  the  initial  tableau, 
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assertions 

goals 

f(a) 

CK--1 

= 

-4) 

A, 

in  theory  TH,  the  program  f(a)  ■$=  t[a]  is  correct  with  respect 
to  the  specification 


/(a)  •<=  find  x  such  that  Q[a,z] 


in  TH.  □ 

The  proof  is  omitted. 

Property  (Final  Tableau) 

A  closed  term  t  satisfies  any  tableau  containing  the  final 
assertion 


false 


t 


or  the  final  goal 


true 


1 


in  any  theory  TH.  □ 

Let  us  prove  this. 

Proof  (Final  Tableau  Property) 

Suppose  the  tableau  contains  the  final  goal, 


true 


t 


Then  for  any  model  2  of  the  theory,  the  truth  condition  holds 
because  true  is  true  under  1,  and  the  output  condition  holds 
because  t  equals  t  under  1.  □ 


B.  Justification  of  a  Deduction  Rule 

Our  deductive  system  will  have  several  deduction  rules. 
Furthermore,  if  we  wish  to  apply  the  system  to  a  particular 
theory,  it  may  be  convenient  to  introduce  new  rules  peculiar 
to  that  theory.  To  establish  the  soundness  of  these  rules,  we 
introduce  a  general  method  for  justifying  deduction  rules. 

For  each  rule  we  formulate  a  justification  condition.  If  the 
justification  condition  holds,  then  the  rule  is  sound.  This  is  the 
content  of  the  following  result. 

Property  (Justification) 

A  deduction  rule  is  sound  in  theory  TH  if  the  following 
justification  condition  holds: 


for  any  model  Ir  for  theory  TH, 
there  exists  a  model  lg  for  TH  such  that 
for  any  closed  primitive  term  t, 

if  t  suits  the  generated  tableau  Tg  under  lg 
then  t  suits  the  required  tableau  Tr  under  2r 
and 

t  suits  the  old  tableau  Ta  under  lg 
if  and  only  if 

t  suits  Ta  under  1T.  □ 

The  justification  condition  suffices  to  establish  that,  when 
we  add  the  generated  rows  to  the  tableau,  we  are  not  altering 
the  set  of  primitive  satisfying  terms. 

Proof  (Justification  Property) 

Suppose  that  the  justification  condition  holds  for  a  deduction 
rule.  We  would  like  to  show  that  the  rule  is  sound.  In  other 
words,  we  must  show  that  the  new  tableau  and  old  tableau 
specify  the  same  class  of  primitive  closed  terms.  Because  we 
are  adding  new  rows  but  not  deleting  any,  we  cannot  lose 
any  primitive  closed  terms  in  applying  the  rule;  we  merely 
must  ensure  that  we  do  not  gain  any.  In  other  words,  we  must 
guarantee  that  for  any  primitive  closed  term  t, 
if  t  satisfies  T„  in  theory  TH 
then  t  satisfies  T0  in  TH. 

Suppose  t  does  satisfy  Tn  in  TH;  we  must  show  that  t  also 
satisfies  T0.  Consider  an  arbitrary  model  1T  for  TH;  we  would 
like  to  show  that 

t  suits  T0  under  1T. 

We  have  supposed  that  the  justification  condition  holds  for 
this  deduction  rule.  Let  2g  be  the  model  corresponding  to  1T 
whose  existence  is  guaranteed  by  the  justification  condition. 
Because  we  have  supposed  that  t  satisfies  Tn  in  theory  TH, 
we  know  that 

t  suits  Tn  under  Ig. 

The  new  tableau  Tn  consists  of  the  original  rows  T0  plus  the 
generated  rows  Tg.  To  suit  the  entire  tableau  T„,  the  term  must 
suit  one  of  these  two  subtableaux.  We  distinguish  between  two 
cases. 

Case:  t  suits  T0  under  2g 
Then  by  the  justification  condition, 
t  suits  T0  under  lr 
as  we  wanted  to  show. 

Case:  t  suits  Tg  under  Ig 
Then  by  the  justification  condition  again, 
t  suits  Tt  under  lr. 

But  since  %  is  a  subtableau  of  the  old  tableau  Tc,  we  have 
t  suits  Ta  under  1T , 

as  we  wanted  to  show.  □ 

The  justification  property  can  be  used  to  show  soundness  of 
rules  that  do  not  preserve  the  equivalence  of  the  tableau.  If  a 
rule  does  preserve  equivalence,  it  is  automatically  sound  and 
there  is  a  simpler  way  to  show  that  it  preserves  equivalence. 
Property  (Justification  for  Equivalence) 

A  deduction  rule  preserves  equivalence  in  theory  TH  if  the 
following  justification  condition  for  equivalence  holds: 
for  any  model  I  for  theory  TH, 
for  any  closed  term  t, 

if  t  suits  the  generated  tableau  Tg  under  1 

then  t  suits  the  required  tableau  Tr  under  1.  □ 
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Proof  (Justification  for  Equivalence  Property) 

Suppose  that  the  justification  condition  for  equivalence 
holds  for  a  deduction  rule.  We  would  like  to  show  that  the 
rule  preserves  equivalence.  In  other  words,  for  each  model  2 
for  TH,  we  must  show  that  the  sets  of  terms  that  suit  the  two 
tableaux  are  the  same.  Because  the  rule  adds  but  never  deletes 
rows,  we  cannot  lose  any  suiting  terms  in  applying  the  rule; 
but  we  must  ensure  that  we  do  not  gain  any.  In  other  words, 
we  must  show  that,  for  any  closed  term  t, 
if  t  suits  Tn  under  2 
then  t  suits  Ta  under  2. 

Suppose  t  does  suit  T„  under  2;  we  must  show  that  t 
also  suits  T0.  Because  t  suits  Tn,  it  must  suit  either  the 
original  subtableau  Ta  (as  we  wanted  to  show)  or  the  generated 
subtableau  Tg  under  2. 

If  t  suits  Tg  under  2,  the  justification  condition  for  equiva¬ 
lence  tells  us  that  it  also  suits  Tt,  and  therefore  Tn,  under  I, 
as  we  wanted  to  show.  □ 

Let  us  use  the  justification  condition  for  equivalence  to  show 
the  soundness  of  the  if-split  rule. 

Property  (Soundness  of  If -Split) 

The  if-split  rule  preserves  equivalence  of  tableaux,  and 
hence  is  sound,  in  any  theory  TH.  □ 

The  proof  of  the  soundness  of  the  if-split  rule  requires  a 
technical  notion  that  will  also  be  useful  later. 

Definition  (Closing  Substitution ) 

Let  e  be  any  expression,  be  a  complete  list 

of  all  the  free  variables  in  e,  and  a  be  a  constant.  Then 
the  substitution  =  {yi  *—  a,  ■  ■  • ,  yn  *—  o}  is  a  closing 
substitution  for  e. 

In  the  case  in  which  there  are  no  free  variables  in  e,  that  is, 
if  e  is  closed,  we  take  the  closing  substitution  AQ  —  {  }.  □ 

Note  that,  if  Aa  is  a  dosing  substitution  for  e,  then  e\a  is 
closed. 

Proof  (Soundness  of  If-Split) 

We  show  that  the  justification  condition  for  equivalence 
holds  for  the  if-split  rule. 

Let  I  be  a  model  for  the  theory  TH  and  t  be  any  closed 
term.  We  suppose  that  t  suits  the  generated  tableau  Tg  under 
2,  and  show  that  then  t  suits  the  required  tableau  Tr  under  2. 

If  t  suits  the  generated  tableau,  it  must  suit  at  least  one  of 
the  two  rows 


A 

$ 

Q 

$ 

that  is,  the  truth  condition  holds  (if  A  then  G)XXa  is  closed 
and  true  under  2. 

Because  sX  is  closed,  sAA0  is  identical  to  sA,  and  hence  we 
have  the  output  condition 

sAA0  is  closed  and  equal  to  t  under  2. 

This  establishes  that  t  suits  the  required  tableau  Tr, 


i  f  A  ihen  £  s 


under  2,  as  we  wanted  to  show. 

The  proof  for  the  case  in  which  t  suits  the  generated  goal 
is  the  same.  □ 

C.  Simplification 

Before  we  introduce  the  rules  of  our  system,  we  would  like 
to  describe  the  simplification  process.  This  is  a  process  in 
which  subexpressions  of  the  tableau  are  replaced  by  simpler 
expressions.  Simplification  can  be  applied  to  the  assertions, 
goals,  or  output  entries  of  the  tableau.  Subsentences  are 
replaced  by  equivalent  sentences,  and  subterms  are  replaced  by 
equal  terms.  The  set  of  simplifications  to  be  applied  depends  on 
the  background  theory,  although  some  simplifications  can  be 
applied  in  any  theory.  Because  the  result  of  a  simplification  is 
always  simpler  than  the  given  expression,  termination  of  the 
process  is  guaranteed. 

Simplification  is  not  regarded  as  a  deduction  rule.  While 
a  rule  adds  new  rows  to  a  tableau  without  changing  those 
that  are  already  present,  simplification  replaces  an  old  row 
with  a  new  one.  Also,  while  the  application  of  a  deduction 
rule  is  at  the  discretion  of  a  user  or  control  strategy,  the 
simplification  process  is  mandatory  and  automatic.  That  is,  we 
shall  fully  simplify  all  the  rows  of  our  tableau  before  applying 
any  deduction  rule. 

Example  (Simplification) 

The  and-two  simplification, 

J-  A  T  =>•  T 

allows  any  subsentence  of  the  form  (T  A  T)  to  be  replaced  by 
the  corresponding  sentence  T.  Applying  that  simplification, 
we  replace  the  row 


9(*) 


P(r)  V(q(a)  A  9(a)) 


We  suppose  it  suits  the  assertion.  Then  for  some  suiting 
substitution  A,  we  have,  by  the  truth  condition, 

AX  is  closed  and  false  under  2 
and,  by  the  output  condition, 

sA  is  closed  and  equal  to  t  under  2. 

Let  Aa  be  a  closing  substitution  for  QX.  We  show  that  t  suits 
the  required  tableau  Tt  under  2,  with  suiting  substitution  AAa. 

Because  AA  is  closed,  AAA0  is  identical  to  AX,  and  hence 
is  closed  and  false  under  2.  Therefore,  by  the  semantic  rule 
for  if-then,  (if  AAAa  then  GXXa)  is  closed  and  true  under  2; 


with  the  corresponding  row 


p(x)  V  q(a) 


g(r) 


□ 


We  arbitrarily  divide  our  simplifications  into  categories. 
The  true-false  simplifications  replace  subsentences  containing 
instances  of  the  truth  symbols  true  or  false.  For  example,  the 
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and-true  simplification, 


T  A  true  =>  T 


Rule  (And-Split) 

In  tableau  notation, 


and  the  not-false  simplification, 

-i false  =>  true 

are  true-false  simplifications.  We  provide  a  full  set  of  these, 
so  that,  after  simplification,  a  sentence  will  contain  no  proper 
suboccurrences  of  the  truth  symbols  true  or  false. 

There  are  other  logical  simplifications  that  are  not  true-false 
simplifications,  such  as  the  or-two  simplification, 

TV  T^>T 

the  cond-term-two  simplification, 

if  T  then  s  else  s  =>  s 

and  the  all-redundant-quantifier  simplification, 

(V  x)T  =>  T ,  where  x  does  not  occur  free  in  T. 

Finally,  there  are  theory  simplifications,  whose  application 
is  limited  to  a  particular  theory.  For  example,  if  our  back¬ 
ground  theory  is  the  nonnegative  integers,  we  include  the 
plus-zero-right  simplification  for  addition, 

u  +  0  =>  u. 

In  the  theory  of  strings,  we  have  the  left-empty  simplification 
for  concatenation, 


A*  v  =>  v. 

V.  The  Deduction  Rules 

We  are  now  ready  to  introduce  the  deduction  rules  of  our 
system.  We  divide  them  into  several  categories: 

•  Splitting  rules.  Break  down  a  row  into  its  logical  com¬ 
ponents. 

•  Resolution  rule.  Performs  a  case  analysis  on  the  truth 
of  a  subsentence  of  two  rows. 

•  Equivalence  rule.  Replaces  a  subsentence  with  an  equiv¬ 
alent  sentence. 

•  Skolemization  rules.  Remove  quantifiers. 

•  Equality  rule.  Replaces  a  subterm  with  an  equal  term. 

•  Mathematical  induction  rule.  Assumes  that  the  desired 
program  behaves  correctly  on  inputs  smaller  than  the 
given  one. 

We  describe  the  splitting  rules,  the  resolution  rule,  the  equal¬ 
ity  rule,  and  the  mathematical  induction  rule  subsequently. 

A.  The  Splitting  Rules 

These  rules  are  logically  redundant:  any  theorem  that  can  be 
proved  with  the  help  of  the  splitting  rules  can  also  be  proved 
without  them.  Nevertheless,  splitting  rules  often  clarify  the 
presentation  of  a  proof. 

We  include  three  splitting  rules  in  our  system: 


A]  A  A-j 

s 

A, 

S 

A-2 

J 

5 

In  other  words,  an  assertion  that  is  a  conjunction  can  be 
decomposed  into  its  two  conjuncts.  The  output  entries  of  the 
required  assertion,  if  any,  are  inherited  by  the  two  generated 
assertions.  If  the  required  row  has  no  output  entries,  neither 
do  the  generated  rows.  □ 

The  or-split  rule  is  similar: 

Rule  (Or-Split) 


Q\  vft 

s 

c. 

s 

s 

In  other  words,  a  goal  that  is  a  disjunction  can  be  decomposed 
into  its  two  disjuncts.  □ 

The  and-split  and  or-split  rules  reflect  the  meaning  of  the 
tableau:  there  is  an  implicit  conjunction  between  the  assertions 
of  our  tableau  and  an  implicit  disjunction  between  the  goals. 
Note  that  there  is  no  or-split  rule  for  assertions  and  no  and-split 
rule  for  goals. 

We  have  seen  the  if-split  rule: 

Rule  (If-Split) 


i  f  A  then  Q 

Q 

A 

.H 

In  other  words,  an  implication  can  be  split  into  an  assertion 
and  a  goal,  its  antecedent  and  consequent,  respectively.  □ 
The  if-split  rule  reflects  the  intuitive  proof  method  that,  to 
prove  a  sentence  (if  A  then  Q),  assume  the  antecedent  A  and 
attempt  to  prove  the  consequent  Q.  The  justification  for  the  if- 
split  rule  was  used  to  illustrate  the  justification  properly  for 
equivalence.  The  justification  for  the  other  splitting  rules  is 
similar. 

Example  (If  Split  Rule) 

Suppose  our  tableau  contains  the  goal 


if  c  >  0 

then  r2  <  r  A  r  <  (;  +  f)* 
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Then  we  may  add  its  antecedent  as  the  assertion 


f  >  0 


Before  discussing  the  ramifications  of  this  rule,  we  illustrate 
it  with  an  example. 

Example  (Resolution  Rule) 

We  apply  the  rule  to  a  goal  and  a  copy  of  itself.  Assume 
our  tableau  contains  the  row 


and  its  consequent  as  the  goal 


-2  <  r  A  7  <  <-  +  f)2  7 

□ 

B.  The  Resolution  Rule 

The  resolution  rule  is  a  nonclausal  version  of  the  classical 
Robinson  [36]  resolution  principle,  introduced  for  program 
synthesis  [23];  a  similar  nonclausal  resolution  rule  was  de¬ 
veloped  independently  by  Murray  [31].  The  rule  corresponds 
to  a  case  analysis  in  an  informal  argument,  and  it  accounts  for 
the  introduction  of  conditional  terms  in  program  derivation. 
We  present  it  first  as  it  applies  to  two  goals. 

Rule  (GG -Resolution) 


Gt\V) 

s 

G-’[V'\ 

1 

G\  8[  false] 

A 

Q26\true] 

if  vs 

then  1 6 

else  sS 

<  r  A  1 

(-  +f)2<r 

- 

(We  shall  explain  the  box  and  minus-sign  annotations  subse¬ 
quently.)  This  row  has  the  variable  z  in  common  with  itself; 
therefore  in  the  copy  we  rename  z  to  z: 


?a<  r  ( A  — '  [(?+  ( )2  <  r] 


The  boxed  subsentences  V  :  (z  +  e)2  <  r  and  V  :  z2  <  r 
are  unifiable:  a  most-general  unifier  is  z  <—  z  +  e.  The  unified 
subsentence  V8  is  then  (z  +  e)2  <  r. 

We  apply  8  to  the  two  rows;  the  original  row  is  unchanged, 
but  the  renamed  copy  becomes 


We  replace  all  copies  of  V8  in  the  instantiated  original  row 
with  false,  and  all  occurrences  of  V8  in  the  instantiated  copy 
with  true.  The  conjunction  of  the  resulting  goals  is  added  to 
the  tableau  as  a  new  goal: 


More  precisely,  the  rule  allows  the  following  inference; 

•  We  take  G\  and  G2  to  be  goal  rows  with  no  free  variables 
in  common;  we  rename  the  variables  of  these  rows  to 
achieve  this,  if  necessary. 

•  We  require  that  V  and  V  be  free,  quantifier-free  sub- 
sentences  of  G\[P]  and  GtKP\  respectively,  that  are 
unifiable.  We  let  8  be  a  most-general  unifier  of  these 
sentences;  thus  V8  and  V'8  are  identical.  In  general,  there 
can  be  more  than  one  subsentence  V  in  Gi\V],  and  more 
than  one  subsentence  V  in  Gzffi']'-,  we  take  8  to  be  a 
most-general  unifier  of  all  these  subsentences. 

•  We  replace  all  occurrences  of  V8  in  G\8  with  false, 
obtaining  Gi8[false)\  we  replace  all  occurrences  of  V'8 
(that  is,  V8)  in  G28  with  true,  obtaining  G28[truc], 

•  We  take  the  conjunction  of  the  results,  obtaining 
(Gi8[fa.lsc]  A  G28[true}).  After  simplification,  this  is 
added  to  the  tableau  as  a  new  goal. 

•  The  output  entry  associated  with  the  new  goal  is  the 

conditional  term  ( if  V8  then  t6  else  s8).  The  test  of 
this  conditional  is  the  unified  subsentence  V6.  The  then- 
term  and  the  else- term  are  the  appropriate  instances  td 
and  s8,  respectively,  of  the  output  entries  of  the  required 
goals.  □ 


z2  <  r  A  {-'false) 

if  (;  +  f )‘  <  r 

A 

then  :  +  f 

true  A  — >[({ -  +  f)  +  ()J  <  i'] 

J 

else  z 

The  output  entry  of  the  new  goal  is  a  conditional  term  whose 
test  is  the  unified  subsentence  and  whose  /hen-term  and  else - 
term  are  the  appropriate  instances  of  the  output  entries  of  the 
two  required  rows. 

The  derived  row  is  simplified  to 


-2  <  r  A  -.[(;  + 2  f)'J  <  rj 


if  [:+()-  <r 


then  -  +  <f 


else  z 


The  simplifications  that  were  applied  to  the  goal  are  the 
true-false  simplifications, 

-1  false  =>  true 
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T  A  true  =$  T 
true  A  T  T 

and  the  numerical  simplification 

(u  +  v)  +  v  =>  u  +  2v.  C 

Digression  (Binary  Search) 

Let  us  interrupt  the  exposition  a  moment  and  discuss  the 
intuition  behind  the  step  in  the  preceding  example. 

The  given  goal, 


-2  <  r  A  — >((=  +  e)2  <  r] 


is  a  consequence  of  the  initial  goal  from  the  derivation  of 
the  rational  square-root  program.  It  expresses  the  fact  that  we 
would  like  to  find  a  nonnegative  rational  number  2  that  is  an 
approximation  within  e  less  than  the  exact  square  root  of  r. 
That  is,  y/r  should  lie  in  the  half-open  interval  [z,  z  +  e).  If 
we  succeed,  2  will  be  a  suitable  output  for  the  program. 

The  derived  row, 


r2  <  r  A  ->[(-  +  2e)2  <  r] 


if  (z  +  <)2  <  r 
then  -  +  e 
else  z 


expresses  the  fact  that  it  suffices  to  find  a  nonnegative  rational 
z  that  is  a  cruder  approximation,  within  2e  less  than  the 
exact  square  root  of  r.  That  is,  y/r  should  lie  in  the  interval 
[z,z  +  2e).  If  so,  the  conditional  term 
if  (z  +  e)2  <  r 
then  z  +  e 
else  z 

will  be  a  suitable  output  for  the  program. 

Why  is  this?  Note  that  z  +  e  is  the  midpoint  of  the  interval 
[2,2  +  2e).  In  the  case  in  which  (z  +  e)2  <  r,  that  is, 
z  +  e  <  y/r,  we  know  that  y/r  lies  in  the  right-half  of  the 
interval.  But  then  the  then-term  z  +  e  is  within  e  less  than  the 
exact  square  root  of  r. 

In  the  alternative  case,  in  which  r  <  (2  +  e)2,  that  is 
y/r  <  z  +  e,  we  know  that  y/r  lies  in  the  left-half  of  the 
interval  [2, 2  +  2e).  But  then  the  else-term  2  is  already  within 
e  less  than  the  exact  square  root  of  r. 

In  either  case,  the  value  of  the  conditional  term  is  within  e 
less  than  the  exact  square  root  and  hence  is  a  suitable  output 
for  our  program. 

The  derived  row  contains  the  basis  for  the  idea  of  binary 
search,  while  the  given  row  does  not.  This  discovery  was 
obtained  by  a  mechanical  step,  a  single  application  of  the 
resolution  rule.  □ 

C.  No-Conditional  Cases 

In  applying  the  resolution  rule,  we  normally  introduce  a 
conditional  term  as  the  output  entry  for  the  derived  row.  There 


are  some  cases,  however,  in  which  we  apply  the  rule  without 
introducing  a  conditional. 

Suppose  that  the  output  entries  s  and  t  of  the  required  rows 
happen  to  be  unified  by  the  substitution  9 ;  that  is,  s8  and  t8 
are  identical.  In  this  case,  the  conditional  output  entry 
if  V6 
then  t9 
else  s8 

is  simplified  by  the  cond-term-two  simplification 
if  T  then  u  else  u  =$  u 

to  yield  s9.  Thus  in  this  case  the  rule  introduces  no  conditional 
term  at  all.  The  resulting  program  is  of  course  more  efficient 
than  if  the  conditional  had  been  introduced.  Moreover,  if  the 
test  V8  is  not  primitive,  we  may  not  know  how  to  compute 
the  conditional  at  all. 

Suppose  now  that  one  of  the  two  required  goals,  say  C?2>  has 
no  output  entry.  Then  instead  of  the  conditional,  the  output 
entry  for  the  generated  goal  will  be  simply  s8,  where  s  is  the 
output  entry  for  Q\. 

Why  is  this?  By  the  no-output  property,  the  goal  G2 
with  no  output  entry  is  equivalent  to  one  with  the  new 
variable  u  as  output  entry,  where  u  does  not  occur  free 
in  the  row  and  is  unaffected  by  9.  The  output  entry 
generated  by  the  standard,  conditional  case  of  the  rule  is 
(if  V8  then  u9  else  s8).  Because  u  is  unaffected  by  8,  this  is 
(i f  V8  then  u  else  s8).  By  the  instance  property,  we  may  add 
to  our  tableau  the  instance  of  that  row  whose  goal  is  the  same 
but  whose  output  entry  is  (if  V6  then  s8  else  s9),  which 
again  simplifies  to  s9.  We  shall  call  this  the  “one-output” 
case. 

Suppose,  finally,  that  both  goals  have  no  output  entry;  then 
the  derived  goal  has  no  output  entry  either.  Why?  By  the 
no-output  property,  again,  the  first  goal  is  equivalent  to  one 
with  output  entry  v,  where  v  is  a  new  variable.  By  the  one- 
output  case  of  the  resolution  rule,  we  may  associate  with 
the  goal  the  output  entry  v8,  that  is,  v.  But  then,  by  the 
no-output  property  again,  that  output  entry  can  be  dropped 
altogether. 

The  no-conditional  cases  of  the  resolution  rule  will  be  il¬ 
lustrated  after  we  have  introduced  the  dual  versions. 


D.  Dual  Versions  of  the  Resolution  Rule 

We  have  presented  the  resolution  rule  as  it  applies  to  two 
goals.  With  the  duality  property,  we  can  justify  dual  versions 
of  the  rule,  that  apply  to  two  assertions,  or  to  an  assertion  and 
a  goal.  These  may  be  expressed  as  follows: 

Rule  (AA-Resolution) 


MV) 

s 

M\V'\ 

t 

Ai8[  false] 

V 

Ai8\tTv.e\ 

if  VB 
then  tB 
else  sB 
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Rule  (AG -Resolution) 


A.|  V\ 

s 

Q2\V\ 

t 

A 

Q26[true\ 

if  VS 
then  18 
else  sS 

We  would  like  to  apply  the  AG  version  of  the  resolution  rule 
to  these  rows.  The  two  rows  have  no  variables  in  common. 
The  boxed  subsentences  are  unifiable;  a  most-general  unifier  is 
0  :{u  <—  aj.  z  <—  ai}.  The  result  of  applying  the  AG  version 
of  the  resolution  rule  is  then: 


-> false 

r 

A 

Oi 

true  A  Q\  >2  (1‘2 

Rule  ( GA-Resolution ) 


5i[P] 

s 

A2\V] 

t 

gt8\  false] 

A 

-.(A20[frue]) 

if  VS 
then  tS 
else  s8 

a 


The  notation  restrictions  and  nonconditional  cases  for  these 
dual  versions  of  the  rule  are  the  same  as  for  the  original  (GG) 
version. 

The  justification  for  these  dual  versions  lies  in  first  pushing 
the  assertions  into  the  goal  column  by  negating  them,  then 
applying  the  GG  version  of  the  rule.  For  the  AA  version,  the 
resulting  goal  is  subsequently  pushed  back  to  the  assertion 
column,  negating  it  once  more.  The  resulting  assertion, 

f  ->AiO[false]  \ 

-  A  | 

\  -i*42#  \true\  ) 


which  simplifies  to 


fl  j  ^ 


a  l 


Because  the  assertion  has  no  output  entry,  the  derived  goal 
has  no  conditional;  this  is  a  one-output  case  of  the  rule. 

The  step  illustrated  is  part  of  the  derivation  of  a  program 
to  find  an  upper-bound  for  two  objects  ai  and  d2  in  the  total 
reflexive  theory  TR.  The  intuitive  content  of  the  derived  row 
is  that,  in  the  case  in  which  ai  y  02,  the  term  a\  will  be  a 
suitable  output  for  the  program.  □ 


E.  Polarity 

The  resolution  rule  could  be  applied  with  the  roles  of  the 
two  rows  reversed.  For  instance,  in  the  preceding  section  we 
applied  the  AG  version  of  the  resolution  rule  to  an  assertion 
and  a  goal.  We  could  also  have  applied  the  GA  version  to  the 
same  goal  and  assertion,  obtaining 


is  then  simplified,  with  the  simplification 


to  yield 

Ai  0[false] 

V 

^2  @[true}. 

The  following  application  of  the  resolution  rule  illustrates 
both  the  AG  version  and  the  one-output  case  of  the  rule. 
Example  (Dual  Version,  No-Conditional) 

Suppose  our  tableau  includes  the  assertion 


false  A  y  02 
A 

-ifrtir 


«J 


which  simplifies  to  the  trivial  goal 


false 


«) 


and  the  goal 


j -V  q|  |+  A:  ^  22 


It  is  typical  that,  of  the  two  ways  of  applying  the  rule,  one 
will  not  advance  the  proof.  In  this  section,  we  introduce  a 
syntactic  condition  that  will  allow  us  to  avoid  many  of  these 
fruitless  applications  of  the  resolution  rule. 

Roughly  speaking,  a  subsentence  of  a  tableau  is  of  negative 
(— )  or  positive  (+)  polarity  if  it  is  within  the  scope  of  an  odd 
or  even  number,  respectively,  of  negation  (->)  connectives. 
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Thus,  in  the  goal 


rule,  obtaining 


-1 

[Ip(t)]  A  ->([<7(y)|+)) 

p(x)  is  of  negative  polarity,  because  it  is  within  the  scope  of 
a  single  negation,  but  q(y)  is  of  positive  polarity,  because  it 
is  within  the  scope  of  two  negations.  We  have  annotated  each 
of  these  subsentences  with  its  polarity  symbol. 

We  regard  the  antecedent  T  of  an  implication 
(if  T  then  Q)  as  being  within  the  scope  of  an  additional 
implicit  negation,  because  (if  T  then  Q )  is  equivalent  to 
( (->.?')  or  g).  Also,  while  each  goal  has  positive  polarity,  we 
regard  each  assertion  A  as  having  negative  polarity,  because 
we  could  push  it  into  the  goal  column  by  negating  it,  obtaining 
(-'^4).  We  regard  both  sides  fF  and  Q  of  an  equivalence 
(T  =  Q)  as  having  both  polarities  (±),  because  (T  =  Q )  is 
equivalent  to  (if  F  then  g)  A  (if  g  then  F)\  the  first 
occurrence  of  F  is  within  the  scope  of  an  additional  implicit 
negation,  but  the  second  is  not;  similarly  for  g.  The  i/-part  F  of 
a  conditional  sentence  (if  F  then  g  else  H)  or  a  conditional 
term  (if  F  then  s  else  t)  also  has  both  polarities. 

Example  (Polarity) 

The  following  sentence  is  annotated  according  to  its  polar¬ 
ities: 


1 

[/«/.se  =  y(n)|  A  [false  V  — >g{o )] 
A 


true 


if  p{«) 

then  a 
else  1(a.a ) 


which  simplifies  to 


-.q{a) 


if  p[a) 

then  n 
else  f(n.n) 


This  application  of  the  rule  is  in  accordance  with  the  polarity 
strategy:  The  subsentence  p(x),  which  has  negative  (in  fact, 
both)  polarities,  is  replaced  by  false ;  also,  the  subsentence 
p(a),  which  has  positive  polarity,  is  replaced  by  true. 

We  can  also  reverse  the  roles  of  the  two  goals  in  applying 
the  resolution  rule,  obtaining 


false 


if  />(«) 


A 


then  t{a.  <i) 


[true  =  9(a)]  A  (true  V -15(a)) 


else  a 


Because  the  sentence  is  an  assertion  rather  than  a  goal,  its 
polarity,  and  that  of  all  its  subsentences,  are  reversed.  □ 
Now  that  we  have  defined  polarity  of  a  subsentence  of 
a  tableau,  we  can  use  the  notion  to  describe  a  strategy  for 
restricting  the  resolution  rule. 

Definition  (Polarity  strategy,  for  Resolution) 

An  application  of  the  resolution  rule  is  in  accordance  with 
the  polarity  strategy  if  at  least  one  negative  occurrence  of  the 
unified  subsentences  V  is  replaced  by  false,  and  at  least  one 
positive  occurrence  of  the  unified  subsentences  V  is  replaced 
by  true.  The  positive  and  negative  occurrences  to  which  we 
refer  may  actually  have  both  polarities.  □ 

We  illustrate  the  polarity  strategy  with  an  example. 
Example  (Polarity  Strategy) 

Suppose  our  tableau  contains  the  two  goals: 


~ - ; — r 

Hx,y) 

|p(r)  *  =  q(x) 

"o' 

r 

> 

+ 

ft. 

< 

[ 

P(a)  |  + 

a 

The  boxed  subsentences  are  unifiable,  with  most-general  uni¬ 
fier  {t:  4—  a, y  <—  a}.  Therefore,  we  may  apply  the  resolution 


which  simplifies  to  the  trivial  goal 


This  application  of  the  rule  is  in  violation  of  the  polarity 
strategy,  because  no  negative  occurrence  of  the  unified  sub¬ 
sentences  is  replaced  by  false.  □ 

We  have  illustrated  the  polarity  strategy  with  the  GG  version 
of  the  resolution  rule.  The  strategy  is  precisely  the  same  for  the 
other  versions.  We  must  remember,  however,  that  polarities 
are  reversed  in  assertions. 

Violating  the  polarity  strategy  does  not  always  cause  us 
to  derive  a  trivial  row;  furthermore,  observing  the  strategy 
does  not  always  prevent  us  from  deriving  a  trivial  row. 
Nevertheless,  it  can  be  shown  that  observing  the  polarity 
strategy  never  prevents  us  from  completing  a  proof,  and  in  fact 
never  even  lengthens  the  proof.  Because  observing  the  strategy 
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greaily  reduces  the  number  of  applications  of  the  rule  we  must 
consider,  there  is  little  reason  to  ever  apply  the  resolution  rule 
in  violation  of  the  polarity  strategy. 


F.  Relation  with  Classical  Resolution 

The  question  arises  as  to  how  the  nonclausal  resolution 
rule  presented  here  relates  to  the  classical  clausal  resolution 
principle  introduced  by  Robinson  [36].  The  clausal  version  of 
the  rule  is  only  applied  to  assertions  that  are  in  clausal  form: 
that  is,  they  are  disjunctions  of  literals,  where  each  literal  is 
either  an  atom  or  the  negation  of  an  atom.  If  we  apply  the 
clausal  resolution  principle  to  the  two  clauses 


V  V  Q 
->V  V  71 


Si  PI 

felH 

t 

Q]  0  [false] 

A 

C,j H  [true] 

if  T0 

then  10 

rl.si •  sH 

_ 1 

We  show  that  the  rule  satisfies  the  justification  condition  for 
equivalence.  Let  1  be  a  model  for  TH,  and  r  be  any  closed 
term.  We  suppose  that  r  suits  the  generated  tableau  Tg  under 
1,  and  show  that  r  then  suits  the  required  tableau  Tr  under  J. 

If  r  suits  Tg  under  1,  then  there  must  be  a  suiting  substitu¬ 
tion  A.  In  other  words,  by  the  truth  condition. 


(where  V  is  an  atom  and  Q  and  71  are  themselves  clauses), 
we  obtain 

Q8  v  ne, 

where  9  is  a  most-general  unifier  of  V  and  V. 

On  the  other  hand,  if  we  apply  the  AA  version  of  the 
resolution  rule  to  the  corresponding  two  assertions 


V  V  <2 

~>V  V  R 

C?i0[/aL>e]\  (Q\9  [/a/sejA  \ 

A  A.  that  is,  f  A 
Q2 6  [true]  J  \  Q26  [frue]A  / 

is  closed  and  true  under  1,  and,  by  the  output  condition, 

ifVB  \  (if  VOX  \ 

then  t.6  J  A,  that  is,  f  then  t6X  J 
else  s9  /  V  else  s9 A  / 

is  closed  and  equal  to  r  under  J. 

It  follows  that 

Q\6  [false]  A  is  closed  and  true  under  1 
Q26  [true]  A  is  closed  and  true  under  J 
and  V9X.  tBX ,  s6X  are  all  closed. 

The  proof  distinguishes  between  two  cases. 

Case:  VOX  is  false  under  1 
In  this  case,  we  show  that  r  suits  the  first  row: 


we  obtain  the  new  assertion 


false  V  Q0 
V 

-ifrue  V  R0 


which  simplifies  to 


Q9V710 


This  assertion  corresponds  to  the  same  clause  produced  by  the 
classical  resolution  rule. 

G.  Justification  of  the  Resolution  Rule 

Let  us  now  justify  the  resolution  rule. 

Property  ( Soundness  of  Resolution) 

The  resolution  rule  preserves  equivalence  of  tableaux,  and 
hence  is  sound,  in  any  theory  TH.  □ 

Proof  (Soundness  of  Resolution) 

Let  us  reproduce  the  resolution  rule  here  for  convenience: 


5.  \V\ 


of  Tr  with  suiting  substitution  6 X. 

We  must  show  the  truth  condition,  that 
Qi[P]9X  is  closed  and  true  under  T. 

But  Qi9[false]X  may  be  obtained  from  Q\[V]9X  by  replacing 
some  occurrences  of  the  closed  subsentence  VOX  with  the 
sentence  false,  which  has  the  same  truth-value  in  this  case. 
Also,  Qi9[false\X  is  itself  closed  and  true  under  1.  This 
implies  the  desired  truth  condition. 

We  must  also  show  the  output  condition,  that 
s9X  is  closed  and  equal  to  r  under  1. 

But  the  conditional  term  (i f  V6X  then  tdX  else  s8X)  is,  in 
this  case,  equal  to  s6X  under  1.  Also  the  conditional  term  is 
closed  and  equal  to  r  under  T.  This  implies  the  desired  output 
condition. 

Hence  in  this  case,  r  suits  the  first  row  of  Tr  under  1.  In 
the  alternative  case,  in  which  VOX  is  true  under  I,  we  show 
that  r  suits  the  second  row  of  Tr  under  1,  again  with  suiting 
substitution  8 X.  Hence  in  either  case,  r  suits  the  required 
tableau  Tr  under  1.  This  shows  that  the  rule  satisfies  the 
justification  condition  for  equivalence.  □ 
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H.  The  Equality  Rule 

Normally,  we  describe  the  properties  of  the  functions  and 
relations  of  our  theory  by  introducing  assertions  into  the 
tableau.  For  example,  we  may  describe  the  >  relation  of 
the  total  reflexive  theory  TR  by  introducing  axioms  into  our 
tableau  as  assertions: 


u  y  u 

ny  v  v  11  ^  u 

Proven  properties  may  also  be  introduced  into  the  tableau  as 
additional  assertions,  such  as  the  following  property  of  the 
upper-bound  function  ub : 


u&(u,  u)  H  A 
t>)  y  «’ 


This  approach  is  not  adequate  for  describing  the  equality 
relation,  for  which  we  require  a  large  number  of  so-called 
functional-  and  predicate -subs  tit  utivity  axioms,  such  as 


if  u  =  v  if  u~  v 

then  f(u,w)  —  f(v,w)  then  p{w,u,  x)  =  p(w,v,x). 

Several  such  axioms  may  be  required  for  each  function  and 
predicate  symbol  used  in  our  proof.  If  we  add  all  the  required 
instances,  the  strategic  ramifications  are  disastrous:  these  ax¬ 
ioms  spawn  numerous  consequences  irrelevant  to  the  theorem 
at  hand. 

Most  theorem  provers  successful  at  working  with  the  equal¬ 
ity  relation  have  used  special  equality  rules,  rather  than  rep¬ 
resenting  equality  properties  axiomatically.  The  equality  rule 
we  use  here  is  a  nonclausal  version  of  the  paramodulation 
rule  [46]. 

We  present  the  rule  first  as  it  applies  to  two  assertions. 

Rule  (AA -equality) 


Ai[(=  r] 

— 

s 

Mn 

t 

Ai9\false\ 

V 

A26(  rd) 

-  - - 

•  We  require  that  t  =  r  be  a  subsentence  of  ^41[/,  =  r] 
and  £'  be  a  subterm  of  A2(£')  such  that  t  and  C  are 
unifiable,  with  most-general  unifier  9.  Here,  t  =  r  and 
('  are  free  and  quantifier-free  subexpressions.  As  in  the 
resolution  rule,  there  may  be  many  distinct  subsentences 
t  =  t  in  Ai[t  =  r],  and  many  subterms  £'  in  A2(£');  the 
substitution  9  must  unify  all  the  appropriate  expressions. 

•  We  replace  all  occurrences  of  {t  =  r)6  in  A16  with 
false,  obtaining  Ai8\ false];  we  replace  one  or  more 
occurences  of  i'8  (that  is,  18)  in  A28  with  rd,  obtaining 
A28 (n8).  (Because  we  replace  some  but  not  necessarily 
all  occurrences,  we  use  the  angle  brackets  ( )  rather  than 
the  square  brackets  [  ]  to  denote  replacement.) 

•  We  take  the  disjunction  of  the  results,  obtaining 
(Ai9[false]v  A28{r8)).  After  simplification,  this  is 
added  to  the  tableau  as  a  new  assertion. 

•  The  output  entry  associated  with  the  new  assertion  is  the 

conditional  term  (if  ((.  —  r)8  then  t8  else  s8).  □ 

We  have  presented  the  equality  rule  as  it  applies  to  two 
assertions.  As  with  the  resolution  rule,  we  can  apply  dual 
versions  of  the  equality  rule  to  an  assertion  and  a  goal,  or 
to  two  goals;  the  justification  of  these  versions  of  the  rule 
appeals  to  the  duality  property. 

Also,  as  with  the  resolution  rule,  we  introduce  a  conditional 
term  into  the  output  entry  only  if  both  given  rows  have  output 
entries  that  fail  to  be  unified  by  the  substitution  8.  If  only  one 
of  the  rows  has  an  output  entry  s,  we  take  s8  as  the  new  output 
entry.  If  both  rows  have  output  entries  s  and  t.  that  are  unified 
by  8,  we  take  the  unified  term  s8  as  the  new  output  entry.  If 
both  rows  have  no  output  entry,  neither  will  the  new  row. 

An  application  of  the  rule  is  in  accordance  with  the  polarity 
strategy  if  at  least  one  negative  occurrence  of  an  equality 
i  =  r  is  replaced  by  false;  no  restriction  is  imposed  on  the 
occurrences  of  the  subterms  l' . 

The  equality  rule  allows  us  to  replace  instances  of  the  left- 
term  t  with  corresponding  instances  of  the  right  term  r.  By  the 
symmetry  of  the  equality  relation,  we  can  justify  a  right-to-left 
version  of  the  rule,  which  allows  us  to  replace  instances  of  the 
right  term  r  with  corresponding  instances  of  the  left  term  l. 

We  illustrate  the  equality  rule  with  an  example. 

Example  ( Equality  Rule) 

This  example  is  taken  from  the  transformation  of  a  program 
to  reverse  a  string.  We  are  in  the  process  of  deriving  an 
auxiliary  subprogram  rev2(s,t)  to  reverse  the  string  s  and 
concatenate  it  onto  the  string  t. 

Our  tableau  contains  the  two  goals 


1 

n 

s 

r 

rev2t<oi7(«).  Itead(s)  ■  t) 

r  =  *  t 

~ 

More  precisely,  the  rule  allows  the  following  inference: 

•  We  take  A\  and  A2  to  be  assertion  rows  with  no  free 
variables  in  common;  we  rename  the  variables  of  these 
rows  to  achieve  this,  if  necessary. 


These  rows  have  no  variable  in  common.  The  boxed  subterms 
are  identical  and  hence  unifiable  with  most-general  unifier 
{  }.  The  result  of  applying  a  dual  version  of  the  rule,  the 
GG-equality  rule,  is  then: 
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-i  false 

A 

2  —  reJ)(A)  *  t 

if  s  =  A 
then  2 

else  rev2(tail(s),  head(s)  ■  t) 

which  reduces  under  simplification  to 

Z  =:  t 

if  s  —  A 
then  : 

else.  rei|2(faii(i),  head(s)  ■  1) 

Because  both  terms  have  output  entries,  a  conditional  term 
is  introduced  as  the  new  output  entry.  The  application  is  in 
accordance  with  the  polarity  strategy,  because  the  occurrence 
of  the  equality  ( s  =  A)  is  negative  in  the  tableau.  □ 

Example  (Equality  Rule) 

This  example  is  taken  from  the  derivation  of  a  square-root 
program  in  the  theory  of  nonnegative  rationals.  We  assume 
our  tableau  contains  the  assertion 


(The  condition  0  <  r  is  simplified  to  true  in  the  theory  of 
nonnegative  rationals.)  Because  the  given  assertion  has  no 
output  entry,  no  conditional  construct  is  introduced  in  applying 
the  rule.  The  application  is  in  accordance  with  the  polarity 
strategy,  because  the  occurrence  of  the  equality  (0  •  v  —  0)  is 
negative  in  the  tableau. 

The  intuitive  content  of  the  derived  goal  is  that,  for  the  case 
in  which  r  <  e2,  that  is,  in  which  y/r  is  in  the  half-open 
interval  [0,  e),  we  know  0  is  a  suitable  output  for  the  desired 
square-root  program.  □ 

The  equality  rule  allows  us  to  discard  all  the  equality 
axioms,  except  for  the  reflexivity  axiom  u  =  u,  from  our  initial 
tableau,  without  sacrificing  the  possibility  of  completing  any 
derivation. 

/.  The  Well-Founded  Induction  Rule 

The  well-founded  induction  principle  is  valuable  for  pro¬ 
gram  synthesis  and  other  applications  because  of  its  generality: 
the  induction  principles  of  all  theories  turn  out  to  be  instances 
of  the  well-founded  induction  rule.  In  derivation  proofs,  use 
of  the  rule  corresponds  to  the  introduction  of  recursion,  or 
other  repetitive  constructs,  into  the  derived  program.  Before 
we  describe  the  rule,  we  introduce  the  notion  of  a  well-founded 
relation. 

Definition  (Well-Founded  Relation) 

A  relation  -<  is  well  -  founded  (in  a  theory  TH)  if  there 
are  no  infinite  decreasing  sequences  in  TH;  i.e.,  no  sequences 
X\ ,  aT2?  ^3)  •  •  -  such  that 


(E3  =  o) 


which  is  an  axiom  for  multiplication,  and  the  goal: 


|  2  ■  2  |  <  r  A 

r  <(*  +  «)* 

— 

The  two  rows  have  no  variables  in  common.  The  boxed  sub¬ 
terms  are  unifiable;  a  most-general  unifier  is  {z  «—  0,  v  <—  0}. 
The  result  of  applying  a  dual  version  of  the  equality  rule  is 
then: 


->  false  A 

0  <  r  A 

r  <  (0  +  e)2 

0 

which  reduces  under  simplification  to 

r<f! 

0 

x\  y  X2  and  x2  >  x3  and  -  □ 

For  example,  the  less-than  relation  <  and  the  proper¬ 
substring  relation  -<  ,lring  are  well-founded  in  the  theories  of 
nonnegative  integers  and  strings,  respectively.  (A  string  s  is  a 
proper  substring  of  a  string  t,  written  s  X  U  if  s  and 
t  are  distinct  and  if  the  elements  of  s  occur  contiguously 
in  t.)  On  the  other  hand,  the  less  than  relation  <  is  not 
well-founded  in  the  theory  of  nonnegative  rationals,  because 
1, 1/2, 1/4, 1/8, .. .  constitutes  an  infinite  decreasing  sequence 
under  <. 

Well-founded  relations  are  of  interest  to  us  because  of  the 
following  property. 

Property  (Well-Founded  Induction  Principle) 

For  any  well-founded  relation  -<  in  theory  TH  and  any 
sentence  V[x],  any  closed  instance  of  the  following  sentence 
is  valid  in  TH: 


if  (V  x') 

r 

if  (V  x) 

'if  x  <  x'  ' 

then  V\x] . 

_then  V[x'] 

then  (V  x)V[x\ 

where  x'  does  not  occur  free  in  V[x\.  D 
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In  other  words,  suppose  we  are  trying  to  prove  that  V[x\ 
is  true  for  every  object  x.  For  this  purpose,  it  suffices  to 
consider  an  arbitrary  object  x‘  and  show  that  P[x'j  holds 
under  the  induction  hypothesis  that  V\x]  is  true  for  every  x 
such  that  x  -<  x' .  The  well-founded  induction  principle  is 
called  complete  induction  or  course-of-values  induction  when 
-<  is  taken  to  be  the  less-than  relation  <  over  the  nonnegative 
integers.  It  is  also  called  Noetherian  induction. 

In  the  deductive-tableau  framework,  this  principle  is  repre¬ 
sented  as  a  rule. 

Rule  (Well-Founded  Induction) 


assertions 

goals 

/(«) 

1 

- 

if  x  -<„,  a 
then  C(x,/(x)] 

Here,  Q[a,  z ]  is  the  initial  goal  of  the  tableau;  we  require  that 
z  be  the  only  free  variable  in  the  row.  (If  there  are  several 
output  entries  Z\ , .  .  .  ,zn,  all  of  them  may  occur  free  in  the 
goal.)  The  relation  is  required  to  be  well-founded  in  TH. 
The  function  symbol  /  stands  for  the  function  we  are  trying 
to  compute.  □ 

The  rationale  for  the  induction  rule  is  as  follows.  We  are 
trying  to  construct  a  program  to  compute  a  function  /  that, 
for  a  given  input  a,  will  yield  an  output  2  that  satisfies 
the  input— output  relation  Q[a,z].  It  suffices  to  conduct  the 
derivation  under  the  induction  hypothesis  that  the  function  f 
will  behave  properly  on  each  input  x  that  is  less  than  a  under 
More  precisely,  we  may  assume  inductively  that,  for  each 
input  x  such  that  x  ~i  w  a,  the  output  f(x)  will  satisfy  the 
input-output  relation  Q[x,j{x)\. 


Example  (Well-Founded  Induction  Rule ) 

Recall  that  the  initial  goal  for  the  frotit-last.  derivation  is 


assertions 

goals 

front(s) 

last(s) 

if  -{s  =  A) 

then  char(:2)  A 

s  =  :  1  *  22 

~2 

This  row  says  that  we  would  like  our  program  to  decompose 
a  nonempty  string  s  into  the  concatenation  of  a  string  z\  and 
a  character  22,  so  that  front.(s)  and  last.(s)  can  be  taken  to 
be  Z\  and  22,  respectively. 

According  to  the  induction  rule,  we  may  add  to  our  tableau 
the  new  assertion 


if  x  -<  «•« 

then  if  -i(x  =  A) 
then  char(tast[x)}  A 
x  —  front(x)  *  last(x) 


This  row  corresponds  to  the  induction  hypothesis  that,  for  any 
nonempty  input  x  less  than  s  under  -<„,  the  functions  front 
and  last  will  indeed  decompose  x  into  the  concatenation  of 
string  front(x)  and  character  last(x).  The  relation  -<  w  can 
be  any  well-founded  relation.  □ 

When  the  program  being  derived  has  more  than  one  input, 
the  well-founded  relation  -<„,  applies  to  two  tuples  of  inputs, 
rather  than  to  the  inputs  themselves. 

Example  (Well-Founded  Induction  Rule) 

The  initial  goal  for  the  rational  square-root  derivation  is 


assertions 

goals 

sqrt(r,  e) 

if  e  >  0 

then  x2  <  t  A 

r<(--  +  ef 

- 

According  to  the  well-founded  induction  rule,  we  may  add 
to  our  tableau  as  an  induction  hypothesis  the  assertion 


This  row  declares  that  the  square-root  program  behaves  prop¬ 
erly  for  any  pair  of  inputs  less  than  the  original  inputs  under 
~<  w  The  well-founded  relation  applies  to  two  pairs,  that  is, 
two  2-tuples,  rather  than  to  two  individual  nonnegative 
rationals.  □ 


J.  Recursion  Formation 

The  induction  hypothesis  introduced  by  application  of  the 
induction  rule  contains  occurrences  of  the  function  symbol  /, 
which  denotes  the  function  we  are  trying  to  compute.  If  the 
induction  hypothesis  is  used  in  the  proof,  it  can  happen  that 
terms  of  form  f{t)  will  be  introduced  into  the  output  column 
and  hence  into  the  derived  program.  This  is  the  mechanism  by 
which  recursive  calls  are  introduced  into  the  program. 
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Example  (Recursion  Formation) 

We  have  applied  the  induction  rule  to  the  initial  goal  of  the 
front-last  derivation,  introducing  the  induction  hypothesis 


Example  (Recursion  Formation ) 

In  the  derivation  of  the  rational  square-root  program,  sup¬ 
pose  we  have  derived  the  assertion 


if  x  -<  u,  s 
then  if  -i(.r  =  A) 
then  char(last(x))  A 

(a-  =  ffront(r)  •  J<isf(x)~|) 


This  induction  hypothesis  contains  occurrences  of  the  func¬ 
tion  symbols  front  and  last ,  which  we  are  trying  to  compute. 
Suppose  we  have  also  derived  the  following  goal: 

c/iar(u)  A 
char[z2)  A 
s  =  u  •  |  *  =2  | 

Note  that  the  boxed  subterms  of  the  two  rows  are  unifiable, 
with  most-general  unifier  {z\  ■*—  front(x),  z2  *—  last(x)}. 
By  application  of  the  right-to-left  version  of  the  equality  rule, 
we  obtain,  after  simplification,  the  goal 

x  -<  u.  S  A 

->(x  =  A)  A 

char[  u)  A 

c/iar(tas((x))  A 

s  =  u  ■  X 

u-front(T) 

last(i) 

By  using  the  induction  hypothesis,  we  have  introduced  the 
terms  front(x)  and  last(x)  into  the  output  column.  This  will 
result  in  the  formation  of  recursive  calls  in  the  final  program. 

The  condition  x  -<  ^  s  in  the  goal  has  the  effect  of  ensuring 
that  these  recursive  calls  will  not  cause  a  nonterminating 
computation  of  the  final  program.  If  there  were  an  infinite 
sequence  of  calls  to  either  front  or  last,  the  corresponding 
arguments  would  constitute  an  infinite  sequence  of  strings 
decreasing  with  respect  to  -<  this  would  contradict  the  well- 
foundedness  of  . 

The  condition  ->(x  =  A)  in  the  goal  guarantees  that  the 
argument  to  the  recursive  calls  is  a  legal  input;  i.e.,  that  it 
is  nonempty. 

The  relation  -<  w  to  be  used  in  the  proof  has  not  been  de¬ 
termined;  it  may  be  any  well-founded  relation.  □ 

We  illustrate  recursion  formation  with  another  example. 


This  is  an  immediate  consequence  of  our  induction  hypothesis. 
We  have  earlier  obtained  the  goal 


if  (r  +  ()2  <  r 

z2  <  r  A 
->[(c  +  2e)2  <  r] 

+ 

then  :  +  f 

1 

else  z 

This  was  obtained  by  an  application  of  the  resolution  rule  in 
a  previous  example.  The  boxed  subsentences  of  the  two  rows 
are  unifiable,  with  most-general  unifier  {x  t—  r,  v  <—  2e. 
z  sqrt(r,  2e)}.  By  application  of  the  resolution  rule,  we 
obtain,  after  simplification,  the  goal 


<r,2e)  (r,  f)  A 

2c  >  0 


if  (sqrt(r,2e)  + 1)2  <r 
then  sqrt(r,  2c)  +  f 
else  sqrt(r.  2c) 


By  using  the  induction  hypothesis  in  the  proof,  we  have 
introduced  three  occurrences  of  the  recursive  call  sqrt(r ,  2e) 
into  the  output  column.  The  condition  (r,  2e)  -<  w  (r,  e)  in 
the  goal  guarantees  that  these  recursive  calls  do  not  lead  to  a 
nonterminating  computation.  The  condition  2e  >  0  guarantees 
that  the  arguments  r  and  2e  of  the  recursive  calls  are  legal 
inputs;  that  is,  2e  is  positive.  The  well-founded  relation  -t 
is  yet  to  be  determined.  □ 

K.  Choice  of  a  Well-Founded  Relation 

There  are  many  well-founded  relations  that  can  serve  as 
the  basis  for  an  induction  proof.  Until  the  proof  is  well  under 
way,  it  may  be  difficult  to  determine  which  relation  will  be 
most  convenient  to  use.  Rather  than  attempting  to  choose  a 
relation  at  the  beginning  of  the  proof,  we  prefer  to  start  the 
proof  with  an  unspecifed  relation  so  that  we  can  discover 
those  properties  the  relation  is  required  to  satisfy. 

We  assume  that  a  number  of  relations  are  given  in  advance 
to  be  well-founded,  with  certain  known  properties.  In  addi¬ 
tion,  there  are  mechanisms  for  constructing  new  well-founded 
relations  from  old  ones,  to  satisfy  certain  properties.  When 
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the  required  properties  of  the  unspecified  relation  x  „.  match 
the  properties  of  a  known  or  constructed  relation  xr,  we  can 
choose  x  u.  to  be  that  relation  X  r. 

Example  (Choice  of  a  Well-Founded  Relation) 

in  the  theory  of  strings,  the  proper  substring  relation 
x  stnng  is  given  to  be  well-founded  and  known  to  have  the 
property  that  the  tail  of  a  nonempty  string  is  its  proper 
substring;  that  is, 


last(s)  of  s  and  the  siring  front(s)  of  all  but  the  last  character 
of  s.  The  specification  is 

{find  {z\ .  z2)  such  that 
if  ->(s  =  A) 

then  char(z2)  As  =  :j  *r2 

in  the  theory  of  strings.  Our  initial  goal  is  thus: 


In  a  derivation  of  front-last ,  we  obtain  the  goal 


This  suggests  that  we  take  the  relation  x  w  to  be  the  proper 
substring  relation  X  s(rmS-  We  can  then  apply  the  resolution 
rule  to  these  two  rows,  with  most-general  unifier  {y  «—  s},  to 
obtain,  after  simplification,  the  goal 


□ 

The  selection  of  the  well-founded  relation  may  be  regarded 
as  an  extralogical  step,  to  be  performed  by  an  external  mech¬ 
anism.  Alternatively,  we  can  extend  our  theories  to  include 
well-founded  relations  as  objects.  We  may  then  regard  x  -<w  y 
as  an  abbreviation  for  X  (w,x.y),  where  in  is  a  variable  that 
ranges  over  well-founded  relations.  In  the  above  resolution 
step,  when  we  unified  tail(y )  X  ,(rinJ  y  with  t.ail(s)  -<w  s, 
the  unification  algorithm  would  then  include  w  «—  string  as 
a  replacement  in  the  most-general  unifier.  In  other  words,  the 
choice  of  the  well-founded  relation  would  be  a  byproduct  of 
the  proof  process.  □ 

VI.  Examples 

In  this  section  we  give  some  examples  of  the  derivation  of 
specific  programs. 

A.  The  Front-Last  Derivation 

We  have  not  given  all  the  rules  in  the  system,  but  have 
shown  enough  to  illustrate  a  full  derivation  of  the  front- 
last  program.  This  program,  the  reader  will  recall,  is  to  find, 
for  a  given  nonempty  string  s,  two  outputs:  the  last  character 


Properties  of  the  theory  of  strings,  expressed  as  assertions,  are 
present  in  the  initial  tableau  and  will  be  mentioned  as  we  use 
them. 

By  the  if-split  rule,  we  may  decompose  our  goal  into  its 
antecedent  and  consequent 


2.  i(j!  =  A) 

3.  cliar{:2)  A 

5  =  |  :i  *  ;2  | 

The  output  entries  z\  and  z2  have  been  dropped  from  the 
row  2,  because  these  variables  do  not  occur  free  in  the 
assertion.  We  have  annotated  goal  3  in  anticipation  of  a  future 
step. 

1)  The  Base  Case:  By  the  equality  rule,  applied  to  an  axiom 
for  concatenation, 


and  the  most  recent  goal,  with  most-genera!  unifier 
{z\  <—  A,y  <—  z2},  we  obtain  the  goal 


Note  that  the  first  output  entry  has  been  instantiated. 

By  the  resolution  rule,  applied  to  the  reflexivity  axiom 
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and  the  goal,  with  most-general  unifier  {2:  <—  s,z2  s},  we 
obtain 


5.  dior(.<) 

A 

s 

Now  both  output  entries  have  been  instantiated.  The  intuitive 
content  of  this  row  is  that,  in  the  case  in  which  the  input  string 
*•  consists  of  a  single  character,  front(s)  may  be  taken  to  be 
A,  and  last(s)  to  be  s  itself.  This  wiil  lead  to  the  base  case 
for  the  program  we  are  constructing.  Let  us  set  it  aside  for  a 
while  and  turn  our  attention  to  the  recursive  case. 

2)  The  Recursive  Case:  We  have  earlier  developed  the  goal 


3.  c/inr(:j)  A 

-1 

-2 

s  =  |  ;i  *  ;2  | 

1 

By  the  equality  rule,  applied  to  an  axiom  for  concatenation, 


if  c/iar(u) 

then  fl  (-u  ■  yi )  =  u-  (yi  *  y2)) 


Note  that,  by  use  of  the  induction  hypothesis,  the  recursive 
calls  front(x)  and  last(x)  have  been  introduced  into  the 
output  columns. 

We  next  apply  the  resolution  rule,  again  to  the  induction 
hypothesis  and  the  goal.  Because  these  rows  have  the  vari¬ 
able  x  in  common,  we  rename  the  variable  in  the  induction 
hypothesis: 


7.  if  1'  -<u.s 

then  if  =  A) 

then  I  char(last(T' ))  |~  A 

1'  —  front(x')  *  lastjr') _ 

Applying  the  rule,  with  most-general  unifier  {x‘  ■< —  2:},  we 
obtain 


and  the  goal,  with  most-general  unifier  {zi  +—  u  ■  2/1, Z2  «—  2/2}* 
we  obtain 


By  the  resolution  rule,  applied  to  the  decomposition  property 
for  strings, 


G.  char(v)  A 
charfyi)  A 


-s  =  v  ■  yi  *  V2 


u  ■  yi 


V7 


9.  t  -<  u,s  A 
— •( T  --  A)  A 

char(v)  A 


i  =  U  •  X  |+ 


u  •  froni(r) 


lastlr) 


By  the  induction  rule,  applied  as  always  to  the  initial  goal, 
we  may  assume  the  induction  hypothesis 


By  the  equality  rule,  applied  right-to-left  to  assertion  7  and 
goal  6,  with  most-general  unifier  {yi  <—  front(x ),  2/2  4— 
last(x)},  we  obtain  the  goal: 


if  -i(y  =  A) 

then  |  y  —  head(y )  •  toi/{ y)  |_ 

■ 

J _ 

and  the  goal,  taking  the  most-general  unifier  {y  <—  s. 
u  head(s),x  tail(s)}  we  obtain 


10.  -.(5  =  A)  A 

|  tail{s )  -<„.  5  [+  A 

head(s)- 

-i(taiHs)  —  A)  A 

front(tail(s)) 

cAar(/ica(f(s)) 

last{tail(s)) 
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Note  that  at  this  stage  the  output  entries  are  fully  instantiated. 
It  remains  to  select  the  well-founded  relation  and  to  combine 
the  base  case  and  the  recursive  calls. 

3)  Choice  of  a  Well-Founded  Relation:  Let  us  assume  that 
we  know  the  following  property  of  the  proper  substring 
relation  -^string  * 


By  the  resolution  rule,  applied  to  our  earlier  assertion 


2.  I  -  A) 


and  the  goai,  we  obtain 


if  -'(v  =  A) 


til en |*ait(y)  -<,)r,-,iq  y 


14.  -i|c7iar(s) 

1 

heatH.i)- 

last{tail[a)) 

1 

frOTtt(taiI(s)) 

By  application  of  the  resolution  rule,  taking  -<  to  be  <  string 
and  taking  the  most-general  unifier  to  be  {y  <—  s},  we  obtain 


it. 


=  A)  A 

head(s)' 

-i(tnil(s)  —  A)  A 

front{tail(s )) 

last(tail[s )) 

|  char{head{.i))  \  + 

This  step  has  suggested  that  the  well-founded  relation  be  taken 
to  be  the  proper  substring  relation. 

4)  The  Final  Steps:  By  the  resolution  rule,  applied  to  the 
axiom 


Finally,  by  the  resolution  rule  applied  to  this  goal  and  the 
one  we  set  aside  for  the  base  case, 


5.  |  char(s)  + 

A 

$ 

we  obtain  the  goat 


if  char(s) 

then  A 

if  char(s) 

15.  true 

else  head(s)- 

then  s 

front  (taif(.$)) 

else  last(tail(s)) 

if  -’(y  =  A) 

then  |  char{head(y)) 


and  the  goal,  with  most-general  unifier  { y  <—  s},  we  obtain 


By  this  step,  conditional  terms  have  been  introduced  into  our 
program. 

Because  we  have  obtained  the  goal  true  with  primitive 
output  entries,  we  can  take  this  to  be  the  final  goal  of  our 
tableau.  The  program  we  extract  from  the  proof  is 

f  if  char(s) 


12. 


— >( A  =  A)  A 

head(s)- 

last(tail(s)) 

|  ->(fai7(s)  =  A)  + 

front{tail(s)) 

By  the  resolution  rule,  applied  to  the  trichotomy  property 
of  strings, 


y  =  A  V  c/i«r(y)  V  | 

-i(lai/(y)  =  A)  | 

_ 1 

with  most-general  unifier  {y  «—  s},  we  obtain 


13.  |  ->(s  =  A)  |  +A 

'nchar[s) 

hcad(s)- 

froni(tail(s)) 

last{tail(s)) 

front(s) 


last(s) 


then  A 

else  head(s)  ■  front(tail(s)) 
if  char(s) 

then  s 

else  last{tail(s)). 


B.  The  Final  Square-Root  Program 

We  do  not  give  the  full  derivation  for  the  square-root 
program  we  have  been  using  as  an  example;  it  is  described 
in  Manna  and  Waldinger  [IT].  The  final  program  we  obtain 
is 


sqrt(r,e) 


'  if  max(r,  1)  <  e 
then  0 

<  else  if  ( sqrt(r ,  2e)  +  e)2  <  r 
then  sqrt(r,  2e)  +  c 
,  else  sqrt(r,2e). 
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Let  us  explain  this  somewhat  odd  program,  because  it  illus¬ 
trates  a  more  general  phenomenon. 

Recall  that  the  program  is  intended  to  find  a  rational 
approximation  sqrt(r,  e)  that  is  within  e  less  than  the  exact 
square  root  of  r;  that  is,  y/r  is  to  belong  to  the  half-open 
interval  [sqrt(r,e).sqrt(r,e)  4  e). 

In  the  case  in  which  the  error  tolerance  is  quite  large,  that 
is,  max(r,  1)  <  e,  it  turns  out  that  r  <  e2,  that  is,  y/r  belongs 
to  the  interval  [0,e)  and,  hence,  that  0  is  a  good  enough 
approximation  to  the  square  root  of  r. 

Otherwise,  we  double  our  error  tolerance  and  recursively 
find  an  approximation  sqrt(r,  2e)  that  is  within  2e  less  than 
the  square  root  of  r;  that  is,  y/r  belongs  to  the  interval 
[s<77-t(r,  2e),  sqrt(r ,  2e)  +  2e).  The  program  then  asks  whether 
( sqrt(r ,  2e)  +  e)2  <  r,  that  is,  whether  y/r  is  in  the  right  or 
the  left  half  of  our  interval. 

In  the  case  in  which  y/r  is  in  the  right  half  [agrt(r,  2e)  4  e, 
sqrt(r.2e)  4  2e),  we  can  take  sqrt(r,  2e)  4  f  to  be  our 
approximation  to  the  square  root;  it  is  certain  to  be  within 
e  iess  than  y/r. 

In  the  alternative  case,  in  which  y/r  is  in  the  left  half 
[sqrf(r,  2e),  sqrt{r,  2e)+e),  we  can  take  sqrt(r,  2e)  itself  to  be 
our  approximation.  In  either  case,  the  conditional  expression 
will  yield  an  approximation  within  e  less  than  y/r. 

This  recursive  program  uses  a  binary-search  technique, 
but  it  does  not  resemble  conventional  iterative  binary-search 
algorithms.  Usually,  a  binary-search  algorithm  will  begin  with 
a  very  large  interval  containing  the  desired  output.  It  will 
divide  the  interval  in  half  at  each  iteration,  and  will  retain 
the  half  that  contains  the  output.  The  process  continues  until 
the  interval  is  sufficiently  small;  that  is,  shorter  than  a  given 
error  tolerance. 

Rather  than  dividing  an  interval  in  half  at  each  iteration,  our 
derived  program  doubles  its  error  tolerance  at  each  recursion, 
until  the  tolerance  is  quite  large.  At  this  point,  it  can  form  a 
large  interval  that  contains  the  desired  output.  As  it  unwinds 
from  the  recursion,  it  implicitly  divides  this  interval  in  half, 
just  as  a  conventional  algorithm  does.  Similar  recursive  binary- 
search  programs  may  be  obtained  for  division  and  other 
numerical  problems. 

This  program  was  first  derived  by  purely  formal  manip¬ 
ulation  of  the  rules  of  the  system,  to  explore  the  search 
space,  without  any  expectation  of  finding  a  program  of  this 
form.  When  the  program  was  obtained,  we  did  not  under¬ 
stand  it  and  thought  we  had  made  an  error  in  the  deriva¬ 
tion. 

The  program  as  derived  is  quite  inefficient,  since  it 
contains  several  occurrences  of  the  same  recursive  call 
sqrt(r,  2e).  These  can  be  replaced  by  a  single  recursive  call 
by  ordinary  elimination  of  common  subexpressions.  More 
sophisticated  program  transformation  techniques  [16]  have 
been  applied  to  transform  the  program  into  a  linear  iterative 
form. 


C.  The  Slowsort  Program 

Another  example  of  a  program  obtained  by  forma]  manip¬ 


ulation  is  this  sorting  program  obtained  by  Traugolt  [45]: 


f ;//  =  <) 


sort(l)  <=  < 


then  (} 

else  if  tail(l)  =  (} 
then  l 

else  if  head(l)  <  head(sort(tail(l))) 
then  head(l)  ■  sort(tail{l)) 
else  head(sort(tail(l)))- 

sort(head(l)  ■  tail(sort(tail(l)))) . 


Here,  l  is  a  list  of  numbers,  and  ()  is  the  empty  list.  No 
particular  claims  are  made  for  the  efficiency  of  this  program; 
for  example,  to  find  the  minimum  element  of  tail(l),  the 
program  sorts  it  and  throws  away  all  but  the  first  element.  The 
program  is  unusual  in  that  it  sorts  the  list  without  invoking 
any  auxiliary  programs,  just  basic  list-processing  primitives. 

Traugott  derived  other  sorting  programs  with  this  property 
as  well.  He  also  considered  the  relationship  between  the  proof 
strategy  and  the  form  of  the  extracted  program. 


vii.  Subprograms 

Once  we  have  derived  a  program  /,  we  can  use  it  as  a 
subprogram  in  future  derivations.  We  do  this  by  including  in 
the  tableau  for  these  derivations  an  assertion  stating  that  the 
derived  program  /  does  indeed  meet  its  specification. 

More  precisely,  suppose  we  have  derived  a  program  f(a)  <= 
t 

to  meet  a  specification 

f(a)  4=  find  z  such  that  Q[a,  z ]. 

Then  in  the  initial  tableau  for  the  derivation  of  a  new  program 
g,  we  may  include  the  assertion 


(Vx)Q|a,/(x)] 


which  states  that  /  does  satisfy  its  specification.  If  this 
assertion  is  used  in  the  proof,  the  new  program  g  may  invoke 
the  earlier  program  /.  The  function  symbol  /  is  included  in 
the  primitive  list  for  the  derivation  of  g. 

If  we  choose,  we  may  include  the  program  /  itself  as  an 
assertion  in  the  derivation  for  g.  That  is,  we  may  include  the 
assertion: 


(V  x)[/(x)  =  (] 


in  the  initial  tableau  for  g.  If  we  do  this,  we  have  lost  a  certain 
degree  of  modularity,  because  the  program  for  g  may  depend 
on  the  particular  implementation  for  /.  We  thus  are  no  longer 
free  to  replace  the  program  for  /  with  a  different  program 
meeting  the  same  specification. 


7<X) 


IEEE  TRANSACTIONS  ON  SOFTWARE  ENGINEERING,  VOL.  18.  NO.  8.  AUGUST  1992 


A.  Program  Transformation 

At  this  point  we  illustrate  both  the  formation  of  subpro¬ 
grams  and  the  application  of  deductive  methods  to  program 
transformation  problems. 

We  suppose  we  are  given  a  program 


fi/s=<) 

reverse(s)  ■£=  <  then  s 

y  else  reverse(tail(s))  *  head(s) 

for  reversing  the  characters  of  a  given  string  s.  The  program 
is  inefficient  because,  in  executing  successive  recursive  calls 
to  reverse,  it  will  be  computing  the  concatenation  function 
many  times. 

To  transform  a  given  program,  we  may  regard  that  program 
as  the  specification  for  a  new  program.  For  this  example,  the 
new  specification  is 

reverse!  (s)  <=  find  z  such  that  z  =  reverse(s). 


From  our  initial  goal,  the  definition  of  reverse ,  and  some 
properties  of  strings,  we  eventually  obtain  the  goal 


The  boxed  subsentences  of  the  assertion  and  the  goal  unify, 
with  most-general  unifier  {i  *—  tail(s),  y  <—  head(s)  ■  t, 
z  <—  reverse2{tail(s),  head(s)  -t)}.  By  the  resolution  rule, 
we  obtain 


Of  course,  the  reverse  program  itself  will  satisfy  this  specifi¬ 
cation,  but  different  derivations  will  yield  different  programs, 
some  of  them  more  efficient  than  others. 

Looking  ahead,  the  particular  program  we  shall  derive  is 


reverse!  (s)  <=  reverse2(s,  A) 

where 

i  f  s  —  A 
then  t 

else  rever3e2(tail(s), 
head{s)  ■  t). 

The  auxiliary  subprogram  reverse2(s,t)  may  be  regarded 
as  a  generalization  of  reverse.  It  meets  the  specification 

reverse£(s,t)  <=  f  ind  z  such  that  z  =  reverse(s)  *  t. 

In  other  words,  it  reverses  s  and  concatenates  the  result  with 
t.  To  complete  the  derivation  of  reverse  1,  it  is  necessary  to 
derive  reverse 2. 


Use  of  the  induction  hypothesis  has  accounted  for  the  intro¬ 
duction  of  the  recursive  call  reverse2(tail[s),  head(s)-t)  into 
the  output  entry  and,  ultimately,  into  the  reverse2  program. 

C.  Derivation  of  Reverse! 

Once  we  have  derived  reverse2,  the  derivation  of  the 
program  reverse!  is  simple.  We  begin  with  initial  tableau 


B.  Derivation  of  Reverse2 

We  will  not  give  the  full  derivation  of  reverse2,  but  will 
present  those  steps  relevant  to  our  present  discussion. 

We  begin  with  the  initial  tableau 


assertions 

goals  reverse2(s,  t) 

-  =  reverse(s)  *  f 

The  function  symbols  reverse  and  are  excluded  from  the 
primitive  list,  so  that  they  may  not  occur  in  the  derived 
program.  By  the  well-founded  induction  rule,  we  may  assume 
the  induction  hypothesis 


We  may  include  in  our  tableau  the  assertion  that,  for  all  x  and 
y,  the  program  reverse2{x,y)  does  meet  the  specification 
from  which  it  was  derived: 


We  assume  that  we  have  the  following  property  of  concate¬ 
nation: 
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By  the  equality  rule  applied  to  this  and  the  previous  assertion, 
with  most-general  unifier  {i  <—  reverse(x),  y  <—  A},  we 
obtain 


— ■( .s  =  A)  A 

|  :  =  rFilpr*ip(t<iif(.s))  •  head(s)  + 


rei'erse2[x.  A)  ~  re»erje(a)  | 


By  the  resolution  rule,  applied  to  this  assertion  and  the  initial 
goal,  with  most-general  unifier  (x  «—  s.  z  *—  reverse2(s,  A)}, 
we  obtain  the  final  goal 


This  time,  however,  the  boxed  subsentence  of  the  goal  fails  to 
unify  with  the  boxed  subsentence  of  the  induction  hypothesis. 
Because  the  specification  for  reverse  1  is  less  general  than 
the  specification  for  reverse2,  its  induction  hypothesis  is  also 
less  general:  in  fact,  the  induction  hypothesis  is  not  general 
enough  to  unify  with  the  desired  goal. 


true 


revcr&c2{s .  A) 


From  this  proof,  we  extract  the  program 


reversel  (s)  •£=  reverse2(s,  A). 


D.  The  Need  for  Generalization 

This  derivation  illustrates  a  phenomenon  in  program  syn¬ 
thesis  that  reflects  a  corresponding  observation  in  theorem 
proving.  It  has  been  remarked  that,  in  proving  a  theorem 
by  induction,  it  is  often  necessary  to  prove  a  more  general 
theorem  so  as  to  have  the  benefit  of  a  more  general  induction 
hypothesis.  (This  fact  has  been  exploited  by  the  Boyer-Moore 
theorem  prover  [5].)  Similarly,  in  deriving  a  program,  it  is 
sometimes  necessary  to  derive  a  more  general  program  so  as 
to  have  the  benefit  of  a  more  general  recursive  call. 

To  illustrate  this  phenomenon,  let  us  see  what  would  have 
happened  had  we  begun  the  derivation  of  the  reversel 
program  without  first  deriving  reverse2.  We  begin  with  the 
goal 


assertions 

goals 

reverse! (s) 

c  =  reversc(s) 

= 

By  the  well-founded  induction  rule,  we  may  assume  the 
induction  hypothesis 


if  r  -<  „.  .< _ 

then  |  reverse!  (i)  =  ret)er'.se(iy|  ~ 


As  in  the  derivation  of  the  reverse2  program,  we  may 
obtain,  from  the  initial  goal,  the  definition  of  reverse,  and 
properties  of  strings,  the  new  tow 


£.  Motivation  for  Generalization 

In  our  successful  derivation  for  reversel ,  we  have  assumed 
that  we  were  clever  enough  to  first  derive  reverse2.  If 
we  were  not  given  the  specification  for  reverse2,  could 
we,  or  perhaps  a  system,  be  led  to  discover  it?  In  general, 
automatic  generalization  of  this  sort  is  a  difficult  problem.  We 
speculate  that  appropriate  generalizations  may  be  discovered 
by  observing  regularities  in  the  structure  of  a  derivation 
attempt. 

For  example,  in  the  attempted  derivation  of  reversel 
(assuming  that  reverse2  has  not  yet  been  developed),  we 
begin  with  the  goal 
z  =  reverse(s) 
and  obtain  the  subsentence 

z  —  reverse{tail(s ))  *  head(s). 

If  we  apply  the  same  steps  to  this  subsentence,  as  we  did  to 
the  original  goal,  we  obtain  the  subsentence 

z  =  reverse(tail(tail(s)))  *  head(tail(s))  *  head(s.) 

If  we  can  observe  the  regularity  in  these  goals,  we  may 
be  inspired  to  construct  a  subprogram  to  satisfy  instead  the 
input-output  condition: 
z  —  reverse(s)  *  t. 

This  is  the  specification  for  the  auxiliary  subprogram 
reverse2.  Each  of  the  above  three  subsentences  is  equivalent 
to  an  instance  of  this  condition,  taking  .5  to  be  s.  t.ail(s), 
and  tail(tail(s)),  respectively,  and  t  to  be  A.head(s),  and 
head(tail{s))  *  head(s),  respectively. 

Some  generalizations,  however,  are  more  difficult  to  moti¬ 
vate.  For  example,  in  the  derivation  of  a  unification  algorithm 
[24],  [32],  we  begin  with  a  specification 


(  find  0  such  that 


unify(ex,e2)  <=  < 


eiO  =  e20  A 


(V0) 


if  ei<p  =  e24> 
then  (3A)[<ji  =  0A] 


V 


(V</>)->(ei <j>  —  e2d>)  A 
0  =  nil 


In  other  words,  we  wish  the  program  to  return  a  substitution  6 
that  is  a  unifier  of  e\  and  e2,  and  that  is  more  general  than  any 
other  unifier  <f>.  In  the  case  in  which  ei  and  e2  are  not  unifiable, 
the  program  is  to  return  the  special  object  nil,  which  is  not 
a  substitution. 
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The  details  of  this  derivation  are  outside  the  scope  of  this 
discussion.  For  our  derivation  proof  to  succeed,  we  found 
it  necessary  to  add  to  the  first  disjunct  of  the  specification 
the  new  condition  99,  =  9  that  is,  9  is  idempotent  under 
composition.  Nonidempotent  most-generai  unifiers  are  unin¬ 
tuitive;  for  example,  {x  <—  y }  and  {y  <—  x}  are  idempotent 
most-general  unifiers  of  x  and  y,  but  {x  «—  z,  y  <—  z, 
z  <—  x}  is  a  nonidempotent  most-general  unifier.  On  the  other 
hand,  idempotence  had  not  been  studied  in  connection  with 
unification,  so  we  were  surprised  to  require  its  introduction  into 
the  specification.  (Idempotence  has  been  studied  independently 
in  the  work  of  Eder  [11].) 


VIII.  SPECIALIZED  INFERENCE  RULES 

Progress  in  program  synthesis  depends  on  the  development 
of  techniques  for  automated  deduction,  both  interactive  and 
automatic.  The  inference  rules  we  have  introduced  so  far  are 
very  general:  they  apply  to  proving  theorems  in  any  theory. 
If  we  are  satisfied  with  a  more  specialized  system,  one  which 
is  competent  in  a  particular  theory,  such  as  the  strings,  we 
may  be  able  to  devise  more  powerful  inference  rules  whose 
applicability  is  limited  to  that  theory.  Such  rules  may  be  able 
to  achieve  in  a  single  step  inferences  that  would  otherwise 
require  several  steps. 

The  first  benefit  of  this  is  to  shorten  proofs.  This  is  a  clear 
advantage  in  an  interactive  system,  in  which  each  step  of  the 
proof  requires  some  effort  on  the  part  of  the  user.  For  an 
automatic  system,  a  shorter  proof  may  be  an  advantage  if  it  can 
be  found  more  easily.  Because  introducing  new  inference  rules 
gives  us  more  choices  at  each  stage,  it  can  actually  increase  the 
search  space.  Although  the  proof  is  shorter,  it  may  be  more 
difficult  to  discover. 

A  new  inference  rule  may  pay  for  itself,  however,  if, 
in  addition  to  shortening  the  proof,  it  allows  us  to  discard 
from  the  initial  tableau  some  assertions  that  represent  valid 
properties  of  the  theory.  We  can  do  this  only  if  the  rule 
has  certain  completeness  properties,  which  guarantee  that  in 
discarding  the  assertions  we  are  not  losing  any  opportunity  to 
complete  a  proof.  If  so,  the  rule  may  reduce  the  number  of 
choices  at  each  stage  and  hence  contract  the  search  space. 

A.  Associative-Commutative  Unification  and  E-Unification 

One  way  to  increase  the  power  of  an  inference  rule  is  to 
extend  the  unification  algorithm  to  take  the  properties  of  the 
theory  into  account.  For  example,  the  associative  and  commu¬ 
tative  properties  of  operators,  such  as  the  addition  and  multipli¬ 
cation  functions  in  the  theories  of  numbers  or  the  conjunction 
and  disjunction  connectives  in  any  logical  theory,  may  be 
incorporated  into  an  associative-commutative  (AC)  unification 
algorithm  [43].  While  the  ordinary  unification  algorithm  would 
not  be  able  to  unify  the  two  terms  a  +  (x  +  b)  and  (c  4-  a)  +  b, 
the  AC  algorithm  would,  returning  the  unifier  {x  <—  c}. 

Completeness  results  for  the  algorithm  have  been  estab¬ 
lished;  that  is,  if  the  algorithm  is  adopted,  we  may  discard 
the  associativity  property: 

(u  +  v)  +  w  =  u  +  (u  -I-  w) 


and  the  commutativity  property: 

u  +  v  =  v  +  u 
from  the  initial  tableau. 

Unlike  ordinary  unification,  which  always  returns  a  single 
most-general  unifier,  the  AC  unification  algorithm  may  return 
a  finite  number  of  distinct  unifiers.  For  example,  for  an 
associative-commutative  function  /,  the  result  of  unifying  the 
two  terms  f(a,x)  and  f(b,y)  can  be  either  {x  <—  b,y  <—  a} 
or  {x  <—  f{b,  u),  y  *—  /(a,  u)},  where  u  is  a  new  variable. 

Special  unification  algorithms  have  been  devised  [39]  for 
treating  operators  with  various  combinations  of  properties, 
including  associativity,  commutativity,  identity,  and  idempo¬ 
tence.  More  general  E-unification  algorithms  (e.g.,  [12])  treat 
operators  with  properties  defined  by  a  set  of  equations  supplied 
by  the  user.  Some  of  these  algorithms  produce  multiple  most- 
general  unifiers,  or  even  an  infinite  stream  of  unifiers;  some  are 
not  guaranteed  to  terminate,  whether  they  produce  an  infinite 
stream  or  not. 


B.  Sorted  Unification 

Some  unification  algorithms  have  been  devised  for  dealing 
with  sort  relations;  these  are  the  unary  relations,  such  as 
integer  (x),  string  (x),  or  char(x),  that  serve  to  categorize 
our  set  of  objects.  Sorted  unification  algorithms  (e.g.,  [38]) 
allow  us  to  provide  a  declaration  that  associates  a  particular 
sort  relation  with  each  variable  and  term.  Thus  we  might 
declare  that  x  is  of  sort  integer  and  $  is  of  sort  string. 
The  sorted  unification  algorithm  will  produce  only  replacement 
pairs  x,  *—  t  such  that  x  and  t  are  of  the  same  sort. 

An  advantage  of  using  sorted  unification  is  that  we  can  drop 
from  our  assertions  and  goals  all  subsentences  p{t),  where  p 
is  a  sort  relation.  For  instance,  if  we  have  declared  x  to  be  of 
sort  string  and  y  to  be  of  sort  integer,  the  sentence 
(Vx)(3y)q(x,  y) 
will  be  understood  to  mean 


(Vx) 


if  string(x) 

then  ( 3y)[integer(y )  A  q{x,y)\ 


Some  assertions  may  disappear  completely.  Use  of  sorted 
unification  has  achieved  dramatic  reduction  of  the  search  space 
for  some  problems. 

Extended  unification  algorithms  may  replace  ordinary  unifi¬ 
cation  in  the  resolution  and  other  inference  rules  of  a  deductive 
system.  Where  the  algorithm  may  return  multiple  unifiers  or 
fail  to  terminate,  the  control  for  the  rule  must  be  adapted 
accordingly. 


C.  Special  Inference  Rules 

Another  way  to  specialize  a  deduction  system  to  a  partic¬ 
ular  theory  is  to  introduce  entirely  new  inference  rules.  We 
have  already  seen  how  paramodulation  (our  equality  rule) 
allows  us  to  give  special  treatment  to  the  equality  relation, 
and  thereby  eliminate  such  axioms  as  transitivity  and  the 
functional-substitutivity  of  equality  from  our  initial  tableau. 
Manna  and  Waldinger  [26]  (and,  with  Stickel,  [22])  introduce 
an  analogous  rule  for  dealing  with  ordering  relations;  adopting 
this  rule  allows  us  to  give  special  treatment  to  the  ordering 
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relation.  Bledsoe  and  Hines  give  special  inference  rules  for 
real  numbers  [4]  and  set  theory  [18]. 

We  have  seen  that  we  can  specialize  a  rule  to  a  particular 
theory  or  subtheory  if  we  have  a  special  unification  algorithm 
for  that  theory.  Stickel  [44]  has  shown  that  we  can  also 
specialize  a  rule  if  we  are  given  a  procedure  for  determining 
the  validity  of  sentences  in  a  subtheory.  The  specialized  rule 
can  then  be  used  to  perform  derivations  in  a  combination  of 
the  subtheory  with  other  theories. 

For  example,  suppose  we  have  two  goals 


where  >  is  a  total  reflexive  relation.  The  ordinary  resolution 
rule  cannot  be  applied,  because  the  boxed  subsentences  are 
not  unifiable.  If,  however,  we  have  a  procedure  capable  of 
determining  that,  if  z\  is  taken  to  be  a,  the  disjunction  of  the 
instances 

a  y  b  V  b  y  a 

is  valid  in  the  total  reflexive  theory,  then  the  theory  resolution 
rule  is  able  to  deduce  the  final  row 


Stickel  formulates  completeness  results  that  allow  us  to 
remove  axioms  from  the  initials  tableau,  such  as  the  totality 
axiom 

u  y  v  v  v  >2  u. 

Analogous  theory  extensions  may  be  formulated  for  the  equal¬ 
ity  rule  and  other  inference  rules.  Such  rules  have  been  found 
to  achieve  sizable  reductions  in  the  search  space. 

IX.  Discussion 

There  are,  of  course,  many  aspects  of  program  synthesis 
that  have  not  been  discussed  in  this  paper,  both  because  of 
space  restrictions  and  because  many  of  these  topics  are  still 
being  developed. 

We  have  limited  ourselves  to  discussing  the  synthesis  of 
applicative  programs,  which  return  an  output  but  produce 
no  side  effects.  Some  work  on  the  deductive  synthesis  of 
imperative  programs,  which  may  alter  data  structures  and 
produce  other  side  effects,  is  discussed  in  [28].  We  have  also 
disregarded  the  synthesis  of  concurrent,  real-time,  and  reactive 
programs,  which  may  interact  with  their  environments  (e.g., 
[35]). 
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We  have  considered  specifications  only  in  the  form  of  first- 
order  inpul-output  relations.  In  general,  it  is  necessary  to 
deal  with  higher-order  specifications  that  describe  properties 
other  than  input-output  relations.  For  example,  if  we  are 
constructing  a  pair  of  programs,  we  should  be  able  to  say 
that  one  is  the  inverse  of  the  other. 

We  have  for  the  most  part  ignored  the  efficiency  of  the 
programs  we  construct;  in  fact,  automatically  synthesized 
programs  are  often  wantonly  wasteful  of  time  and  space.  One 
way  of  treating  this  is  to  include  performance  criteria  as  part 
of  the  program’s  specification;  the  synthesized  program  would 
then  be  forced  to  meet  these  criteria.  Another  approach  is  to 
maintain  a  crude  performance  estimate  for  each  output  entry,  in 
a  separate  column.  Performance  estimates  could  be  taken  into 
account  in  directing  the  search  for  a  program.  Furthermore, 
once  a  program  was  constructed,  the  search  could  continue 
for  programs  with  better  performance  estimates,  based  on  a 
better  algorithm  or  data  structure,  for  instance. 

Finally,  we  have  concentrated  on  program  synthesis  to  the 
exclusion  of  the  use  of  deductive  techniques  in  collaboration 
with  other  software  production  methods;  e.g.,  deductive  test¬ 
ing,  debugging,  verification,  modification,  and  maintenance. 

At  present,  progress  in  program  synthesis  is  limited' by 
the  power  of  automated  proof  systems.  Derivation  proofs  are 
an  appealing  and  challenging  area  of  application  for  both 
automatic  and  interactive  theorem  proving. 

For  automatic  systems,  program  synthesis  has  an  advantage 
over  mathematics  as  an  application  area.  To  make  a  contribu¬ 
tion  to  mathematics,  a  system  must  be  able  to  prove  theorems 
that  a  human  mathematician  cannot.  For  this  reason,  theorem- 
proving  systems  such  as  Argonne’s  [21]  have  had  their  greatest 
successes  in  areas  in  which  human  intuition  is  weak,  such  as 
combinatory  logic  and  ternary  Boolean  algebras,  so  that  the 
machine  can  compete  on  a  more  equal  footing.  For  program 
synthesis,  there  is  great  utility  in  a  system  that  can  reliably  be 
expected  to  prove  routine  and  mathematically  naive  results, 
because  from  these  results  we  can  extract  correct  programs. 
The  challenge  is  that  many  such  proofs  are  still  outside  the 
reach  of  current  automatic  deductive  technology. 

To  construct  an  interactive,  rather  than  an  automatic,  pro¬ 
gram  synthesis  system  is  closer  to  an  engineering  feat  today. 
Such  a  system  relies  on  human  intuition  to  guide  the  upper 
levels  of  the  proof  search,  but  itself  completes  the  automatable 
details.  Errors  in  human  guidance  may  delay  the  discovery  of 
a  program,  but  never  cause  the  system  to  construct  an  incorrect 
program.  The  challenge  in  designing  an  interactive  system  is 
to  phrase  the  interaction  in  terms  that  the  human  guide  can 
understand. 
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